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CHAPTER  1 


INTRODUCTION 


1.1  fi*££S£2JZl!£ 

The  Ada  Integrated  Methodology  (AIM)  was  developed  as  a  product 
of  the  Ada  Capability  Study  that  was  conducted  at  General 
Oynaaics  Data  Systems  Division.  This  study  was  perforaed  in 
response  to  a  contract  that  was  awarded  to  General  Dynanics  by 
the  United  States  Department  of  Defense  (DoD) .  The  purpose  of 
the  Ada  Capability  Study  was  to  provide  data/information  to  the 
DoD  that  would  be  useful  in  formulating  an  Ada-based 
communications  system  methodology  and  an  Ada  training  program. 


1.2 


-AM_£msiii2JLSi22i 


The  structure  of  the  study  is  illustrated  in  Figure  1.2-1. 

Rithin  this  structure,  the  methodology  team  developed  AIM  tch 
was  applied  to  the  redesign  of  a  message  switch  system  by 
design  team.  The  redesign  was  a  real-world  case  study  bee;  ~e 
the  system  redesigned  is  currently  in  production. 

Problems  associated  with  the  application  of  AIM  to  the  red*.  *n 
of  the  message  switch  system  were  documented  by  the  design  teas. 
Resolutions  of  these  problems  resulted  in  changes  to  AIM 
throughout  the  project.  AIM,  along  with  the  problems  documented 
and  their  resolutions  were  delivered  to  the  DoD  at  the  conclusion 
of  the  study.  The  intent  was  to  make  this  information  available 
to  the  DoD  as  input  for  making  decisions  relating  to  the  use  of 
Ada  in  the  future. 


1 . 3  OVERVIEW  OF  AIM 

AIR  is  a  requirements  and  design  methodology  developed 
specifically  for  application  to  the  development  of  Ada-based 
communications  systems.  It  integrates  several  existing 
methodologies  and  some  important  design  concepts  with  the  power 
of  the  Ada  language. 

1.3.1  S£2£S 

AIM  was  being  tailored  for  (1)  communication  systems  and  (2)  Ada 
constructs.  Characteristics  of  a  message  switch  system  were 
studied  in  an  effort  to  facilitate  AIM  sensitivity  to 
communication  systems.  Additionally,  Ada  constructs  were  studied 
extensively  for  incorporation  into  AIM.  However,  not  only  Ada 
constructs  themselves,  but  concepts  such  as  information  hiding 
and  abstract  data  types  which  are  supported  by  Ada  were  also 
studied. 


1 


There  are  many  elements  of  existing  methodologies  which  are 
beyond  the  scope  of  this  aethodology  development  effort. 
Specifically,  the  methodology  excludes  the  following: 

Development  of  documentation  and  plans  in  support  of  the 
implementation  of  a  new  system  such  as  (1)  user  guide, 

(2)  operations  guide,  (3)  test  plan,  (4)  new  procedures, 
and  (5)  training  aids  and  courses 

Survey  of  present  system 

Conversion  from  present  system 

Implementation  phase  (does  not  address  programming  and 
testing)  -  goes  through  design  only 

Constraints  such  as  time,  money,  and  personnel 

Detailed  explanations  of  contributing  methodologies, 
concepts,  and  the  Ada  language  (provides  only  basic 
guidelines  and  examples  for  the  requirements  analyst  and 
designer) . 

The  AIN  project  life  cycle  concept  can  be  used  to  help  illustrate 
the  scope  of  AIM  (see  Figure  1.3. 1-1).  The  dotted  lines  on 
Figure  1.3. 1-1  indicate  where  AIM  begins  and  ends.  Although 
there  is  no  implementation  methodology  within  AIM,  Chapter  4  does 
provide  some  Ada  development  standards. 

1.3.2  fiesciiEtifin_gi^d  a^legjiir  ements_Setio  doiggi.  J  AHML 

ARM  is  a  requirements  methodology  for  mapping  A-specifications 
(for  communications  systems)  into  requirments  that  will  be  used 
as  input  to  the  design  process  (see  Figure  1.3. 1-1).  The 
application  of  ARM  results  in  a  set  of  system  requirements 
expressed  in  three  basic  formats  -  (1)  graphic  illustrations 
(models  of  the  system  functions,  logical  data  structures,  and 
concurrency) ,  (2)  structured  English  which  uses  the  Ada  language 
constructs  as  a  base  that  is  augmented  by  a  disciplined  use  of 
the  English  language,  and  (3)  English  narrative. 

The  purpose  of  ARM  is  to  effect  an  understanding  of  the  problem. 
The  requirements  analyst  must  understand  the  problem  and  convey 
this  understanding  to  the  designer  via  the  Ada  Requirements 
Document  produced  by  the  application  of  ARM. 

Three  basic  assumptions  were  made  prior  to  the  development  of 
ARM.  First,  it  was  assumed  that  the  A-specification  document 
needed  to  be  decomposed  and  rewritten  in  a  more  structured  format 
with  graphic  illustrations  in  order  to  eliminate  ambiguity  and 
enhance  clarity.  Secondly,  it  was  assumed  that  the  requirements 
analyst  and  designer  are  not  the  same  person.  Thirdly,  the  Ada 
language  was  assumed  to  be  the  implementation  language. 


1.3. 2.1  >  Derivation 

ABB  was  developed  mainly  from  two  existing  methodologies  - 
Structured  Analysis  (Yourdon  and  De  Marco)  and  SADT  (Sof tech) . 
Both  of  these  methodologies  regnire  functional  decomposition  of 
the  problem  being  studied  during  the  analysis  or  requirements 
phase  of  system  development,  functional  decomposition  night  even 
be  considered  as  the  nucleus  of  both  methodologies.  Therefore, 
ABU  is  heavily  oriented  toward  functional  decomposition.  Also 
the  paper,  "Software  Requirements:  A  Report  on  the  State  of  the 
Art",  pp.  22-30;  Yeh,  Zave,  Conn,  and  Cole;  October  1980,  was  the 
primary  contributor  in  the  non-functional  requirements  area  of 
ABB. 


1.3.2. 1.1  Contribution  of  structured  Analysis 

Structured  analysis  is  a  formal  methodology  for  developing  system 
specifications  or  requirements  that  feed  into  the  design  process. 
As  stated  above,  functional  decomposition  is  the  salient  feature 
of  Structured  Analysis.  A  data  flow  diagram  (DFD)  is  the  vehicle 
used  to  facilitate  functional  decomposition.  Specifically,  a 
high-level  system  diagram  that  shows  all  the  major  functions  of 
the  system  is  decomposed  (by  function)  until  all  major  functions 
have  been  broken  down  sufficiently  for  understanding.  This 
method  of  functional  decomposition  is  employed  by  ABB. 

The  DFDs  created  by  the  application  of  structured  analysis  show 
functions  and  their  interfaces  (data  flows  and  files)  with  each 
other.  ABB  uses  DFDs  in  this  same  manner  with  some  modifications 
from  SADT  (which  are  addressed  in  a  subsequent  section  below) . 

Structured  analysis  also  requires  the  development  of  a  data 
dictionary,  logical  data  structure  models,  and  structured  English 
specifications  that  describe  the  functions  illustrated  by  the 
lowest-level  DFDs.  ABB  requires  the  development  of  these  same 
components.  However,  instead  of  structured  English,  ABB  uses  a 
combination  of  Ada  language  constructs  and  a  disciplined  version 
of  the  English  language  to  state  function  specifications  or 
requirements. 

1.3. 2. 1.2  Contribution  of  SADT 

SADT  employs  some  mechanisms  during  the  development  of  DFDs  that 
have  been  adopted  by  ABM.  Bectangular  blocks  are  used  to 
symbolize  functions  on  SADT  diagrams  instead  of  the  circular 
mechanism  used  by  Structured  Analysis  to  illustrate  functions. 

ABB  employs  SADT's  rectangular  block  representation  of  functions 
during  the  development  of  DFDs. 

SADT  uses  the  four  sides  of  the  block  structures  (functions)  to 
distinguish  between  inputs,  outputs,  control  variables,  and 
man/machine  interfaces.  ARB  employs  this  concept  also. 
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Concurrency  is  not  included  in  SAET  DFDs.  However,  SAOI  does 
recoaeend  addressing  concurrency  after  developing  the  DFDs  for 
the  systee.  ABM  incorporates  this  saae  philosophy. 

1.3. 2. 1.3  Contribution  of  Ada 

Even  though  functional  decomposition  is  the  salient  feature  of 
ABM  and  the  sain  vehicle  for  producing  an  understanding  of  the 
problem,  the  use  of  Ada  as  a  requirements  language  is  the  first 
step  toward  using  Ada  throughout  the  systea  development  life 
cycle.  The  use  of  Ada  as  a  prograa  design  language  (PDL)  during 
design  will  capitalize  on  the  capabilities  of  Ada  even  more  than 
its  use  as  a  reguireaents  language. 

Ada  has  the  constructs  that  support  writing  concise,  unambiguous, 
structured  specifications.  Therefore,  a  subset  of  the  Ada 
language  (which  includes  the  necessary  constructs)  formed  the 
basis  for  a  structured  reguireaents  specification  language  to  be 
used  for  writing  functional  specifications.  The  subset  of  the 
Ada  constructs  utilized  by  ABH  is  provided  below: 

if  stateaent 
case  stateaent 
loop  stateaent 
assignaent  stateaent 
code  stateaent 
expression 
relation 
exit  stateaent 

procedure  calls  fcr  pre-defined  procedures 
raise  stateaent 
exception  handler. 

As  the  reguireaents  specifications  language,  Ada  is  used  to 
express  the  specifications  for  each  lowest  level  (priaitive) 
function  of  the  DFD.  Disciplined  English  is  used  to  suppleaent 
the  Ada  reguireaents  language  constructs  when  they  are 
insufficient  for  representing  a  particular  reguirement. 
Additionally,  consents  are  used  where  appropriate  to  add  clarity 
to  the  reguireaents.  The  syabol  for  a  coaaent  line  is  *— *,  the 
saae  as  the  Ada  coaaent  notation.  A  " — >”  syabol  is  used  to 
indicate  a  line  of  requirements  specifications  that  is  stated  in 
disciplined  English.  Figure  1.3. 2-1  is  an  example  of  an  Ada 
requirements  specification  which  uses  Ada  constructs,  disciplined 
English,  and  comments. 

The  use  of  Ada  as  the  tool  for  expressing  functional  reguireaents 
is  expected  to  provide  a  high  degree  of  continuity  froa 
reguireaents  to  design.  This,  of  course,  should  result  in  fewer 
conversions  from  requirements  to  design  specifications.- 


DFD  DIAGRAM:  A344  MODIFY  MCB 

A- SPECIFICATIONS  REFERENCE:  PARAGRAPHS  3.2.1.2.13.1,  DCAC-370-D175-1 

TABU  8*1 

DESCRIPTION:  EXAMINE  A  RECEIVED  MESSAGE  CONTROL  BLOCK  (MCB)  TO  DETtIMXHE  IP  THE 
MESSAGE  IS  ORBITING;  IP  MOT,  THEM  MODIFY  AS  REQUIRED  TO  PREVENT 
ORBITING,  ADD  THE  TIME  OF  MESSAGE  RECEIPT,  AH>  RECALCULATE  BLOCK 
PAKITT  (BP).  IP  MESSAGE  IS  ORBITING,  NOT ITT  OPERATOR. 

REVISION:  BAAA 
DATE:  12/14/81 
AUTHOR:  P.  DOBBS 

SPECIFICATIONS : 
type  CT  la  8. .2; 

COUNT  :  CT; 
begin 

COUNT  :-8; 

Per  all  CHARACTERS  In  TDM  loop 
If  CHARACTER  -  SWITCH  ID  than 
COUNT  COUNT  +  1; 
end  If; 
end  loop; 
eaae  COUNT  la 
ehen  8  “> 

— >  ADD  SWITCH_ID  TO  FIRST  ZERO  FIELD 
when  l  “> 

— >  ZERO  ALL  FIELDS  AFTER  POSITION  OF  SWITCH  ID 
— >  ADD  SWITCH  ID  SECOND  TIME 
when  2  -> 

— >  HOLD  MESSAGE 
—  PROVIDE  ORBIT  INFORMATION 
-->  NOTIFY  OPERATOR 
end  eaae; 

— >  ADD  SOB  TIME 
BP  MCB(l); 
for  I  In  2.. 83  loop 
BP  :•  BP  xor  MCB(I); 
and  loop; 
end  MODIFTJCB; 


Figure  1.3. 2-1  Exaaple  of  Ada  acquirements  Specification 
1.3. 2. 2  Scope  of  ABU 

ABU  restates  and  graphically  illustrates  system  requirements  in 
the  A-specifications  document  (both  functional  and  non¬ 
functional)  .  It  is  not  intended  to  constrain  or  limit  the 
designer.  However,  the  functional  decomposition  and  creation  of 
EFDs  in  the  requirements  phase  is  considered  by  some  as  moving 
toward  design.  The  intent  of  ABH  is  to  produce  an  understanding 
of  the  problem  and  a  requirements  document  that  will  aid  and 
facilitate  the  design  process.  The  inclusion  of  functional 
decomposition  and  DFDs  in  ABH  is  consistent  with  a  trend  in 
contemporary  system  development  to  incorporate  more  planning. 
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discipline,  and  decision-iaking  up  front  (prior  to  prograa 
development) . 

1.3. 2. 3  Outputs 

The  output  of  ABU  is  an  Ada  Beguireaents  Document.  Components  of 
this  docuaent  are  listed  below: 

a.  Functional  Hodel  of  System  (Data  Flow  Ciagraa) 

b.  Ada  Function  Beguireaents 

c.  Data  Dictionary 

d.  Logical  Data  Structures  Hodel 

e.  Concurrency  Hodel  (s) 

f.  Non-Functional  Beguireaents 

The  Ada  Beguireaents  Docuaent  is  the  vehicle  for  conveying  system 
reguireaents  to  the  designer  and  is  intended  to  feed  into  and 
influence  the  design  process. 

1.3.3  £e§s£ip^ign_gl_ld  j_J2s§igQ.ggt)}gdglggy.  HI 

ADH  is  a  design  aethodology  that  converts  the  output  of  ABH  (Ada 
Bequireaents  Docuaent)  to  a  systea  design  (see  Figure  1.3. 1-1). 
The  application  of  ADH  results  in  a  system  design  expressed  by 
graphic  models  and  Ada  prograa  design  language  (FDL) . 

Several  methodologies  and  design  concepts  have  been  combined  with 
the  Ada  language  to  fora  ADH.  Therefore,  the  designer  that 
applies  ADH  should  be  eguipped  with  a  design  "tool  bag". 

The  purpose  of  ADH  is  two-fold.  First,  ADH  Bust  produce  a  design 
that  satisfies  the  reguireaents  in  the  Ada  Reguireaents  Docuaent. 
Secondly,  it  aust  produce  a  design  that  exhibits  maintainability 
(flexibility  for  design  changes  during  developaent  and  after 
iapleaentation) .  Four  assumptions  influenced  the  developaent  of 
ADH.  These  assuaptions  are  listed  below: 

a.  The  application  of  ABH  produces  an  Ada  Beguireaents 
Docuaent  that  supports  and  influences  a  structured 
design  process. 

b.  The  iapleaentation  language  is  Ada. 

c.  The  design  oust,  above  all,  satisfy  the  systea 
reguireaents  as  stated  in  the  Ada  Beguireaents  Docuaent. 

d.  Haintainability  is  the  theae  that  aust  permeate  the 
design  process. 
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1.3. 3.1  Derivation 

is  stated  above,  ADD  is  a  combination  of  selected  design 
aethodologies,  concepts,  and  the  Ada  language,.  As  a  result, 
there  were  aany  contributors  to  its  developaent. 

1.3. 3. 1.1  Contribution  of  Object-Oriented  Design  (Booch 
and  Jackson) 

The  Of  ‘^ct-Oriented  Design  Hethcdology  as  suggested  by  Grady 
Booch  :  >.i*  article,  "Describing  Software  Design  in  Ada",  has 

been  employed  by  ADB  as  the  first  step  of  the  design  process. 

Sone  concepts  t cob  Bichael  Jackson's  data-driven  design  approach 
have  been  eerged  with  Booch' s  object-oriented  design  approach  in 
this  step. 

The  intent  of  the  object-oriented  design  step  is  to  take  a  first 
cot  at  identifying  the  high-level  objects  of  the  systen  and 
establishing  Ada  packages  around  these  objects  that  exhibit 
infornational  strength.  However,  object-oriented  design  is 
nostly  an  art  and  has  not  been  fcrnalized  as  a  nature  design 
sethodology.  As  a  result,  the  packages  established  during  the 
application  of  object-oriented  design  are  not  ianediately 
incorporated  into  the  systen  design.  Instead,  they  are  put  on 
hold  and  reconciled  with  the  systen  design  produced  later  in  the 
design  phase. 

1.3. 3. 1.2  Contribution  of  Structured  Design  (Yourdon 
and  Constantine) 

Structured  Design  contributed  heavily  to  the  developaent  of  ADH. 

A  structure  chart  (an  iaportant  structured  design  tool)  is 
produced  froa  the  DFD  produced  during  the  reguireaents  phase 
using  Structured  Design  techniques.  Once  the  initial  structure 
chart  is  produced,  it  is  evaluated  in  terns  of  goodness  using  two 
iaportant  structured  design  concepts  (coupling  and  cohesion) . 
Additionally,  soae  Structured  Design  heuristics  are  used  to 
produce  an  initial  structure  chart  and  then  to  evaluate  and 
enhance  it  until  a  satisfactory  functional  design  is  achieved. 

1.3.3. 1.3  Contribution  of  Coaposite  Design  (Byers) 

The  aain  contribution  of  Coaposite  Design  to  the  developaent  of 
ADH  was  to  augment  the  Structured  Design  approach  utilized. 

Byers'  Coaposite  Design  approach  eabraces  aany  of  the  sane 
principles  of  Structured  Design  with  a  little  different  flavor. 
Perhaps  the  most  significant  contribution  of  Coaposite  Design  is 
a  cohesion  concept  called  intonation  strength  which  supports 
information  hiding  and  maintainability. 

1.3. 3. 1.4  Contribution  of  Data-Driven  Design  Approach  (Jackson) 

Bichael  Jackson's  book,  2sirci£le§_o|_£52grga_£esigs,  describes 
the  Data-Driven  Design  approach  which  is  used  at  two  points 
during  the  application  of  ADH.  First,  Jackson's  approach  is  used 
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to  facilitate  object-oriented  design.  System  objects  are 
represented  using  Jackson's  aechanisn  for  representing  data 
structures,  and  operations  are  assigned  to  objects.  Secondly, 
the  Data-Driven  Design  approach  nay  be  applied  to  subprobleas 
during  the  developaent  of  a  structure  chart. 

1.3. 3. 1.5  Contribution  of  Selected  Design  Concepts 

There  are  two  concepts  that  are  very  basic  to  design  -  coupling 
and  cohesion.  Coupling  is  a  aeasure  of  the  quality  and  guantity 
of  the  interfaces  between  the  aodules  of  the  systen.  Cohesion  is 
a  qualitative  aeasure  of  the  functional  strength  of  the  aodules 
in  the  systea  (how  tightly  the  eleaents  of  a  aodule  are  bound) . 
These  two  concepts  are  key  features  of  the  structured  design 
nethodology.  However,  they  are  also  regarded  universally  as 
iaportant  aeasures  of  design. 

Two  other  concepts  that  play  an  iaportant  role  in  the  application 
of  ADH  are  information  hiding  and  abstract  data  types.  These  two 
concepts  are  used  to  enhance  a  design  beyond  what  can  be  achieved 
by  applying  only  coupling  and  cohesion  as  aeasures  of  design. 
Inforaation  hiding  involves  aaking  visible  to  a  aodule  only  the 
data  that  it  needs  in  order  to  perform  its  function.  The  concept 
of  abstract  data  types  promotes  the  developaent  of  operations 
around  an  abstract  data  structure  into  one  aodule.  Ada  supports 
these  design  concepts  better  than  aost  high-level  languages. 

The  four  design  concepts  referenced  above  (coupling,  cohesion, 
inforaation  hiding,  and  abstract  data  types)  heavily  influenced 
the  developaent  of  ADH.  Therefore,  it  is  iaportant  that  the 
designer  have  a  good  knowledge  of  these  concepts. 

1.3. 3. 1.6  Contribution  of  Ada 

ADH  uses  concepts  supported  by  Ada  and  certain  Ada  constructs  to 
help  deteraine  systea  architecture.  It  also  uses  constructs  of 
Ada  as  a  PDL . 

Ada  concepts  that  support  developing  systea  architecture  include 
packaging  and  tasking.  Packaging  is  the  vehicle  used  to  achieve 
inforaational  strength  aodules  in  design.  Inforaation  strength 
is  the  goal  of  object-oriented  design  which  is  applied  by  ADH. 
Tasking  is  used  by  ADH  to  support  concurrency  and  the  performance 
and  real-tiae  constraints  associated  with  a  communications 
systea.  Specifically,  tasking  supports  concurrent  processing  and 
synchronization  which  are  iaportant  characteristics  of 
coaaunication  systems.  The  Ada  task  construct  itself  provides 
for  concurrent  operations  in  the  Ada  environment.  Task 
communication  and  synchronization  between  tasks  (concurrent 
operations)  is  accomplished  through  the  rendezvous  mechanism  in 
Ada. 

Ada  language  constructs  are  used  as  a  PDL  at  two  distinct  points 
in  the  application  of  design,  first,  Ada  is  used  to  express  the 
basic  framework  of  systen  design  before  hardware  components  are 
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identified.  This  first  Ada  PCI  expression  of  system  design 
describes  the  interfaces  between  the  subprograms.  packages,  and 
tasks  within  the  systeo  design  as  they  exist  prior  to 
hardware/software  partitioning.  The  second  Ada  POL  expression  of 
the  system  design  occurs  after  hardware/software  partitioning. 
This  second  expression  goes  beyond  describing  the  basic  framework 
and  interfaces  of  the  systen  design.  It  expresses  the  functional 
requirements  of  each  subprogram  and  package  in  the  system 
architecture.  Additionally,  the  basic  requirements  of  each 
hardware  component  in  the  systen  architecture  is  described  in  the 
second  Ada  POL  expression. 

1.3. 3.2  Scope  of  ADM 

The  application  of  ADM  produces  graphic  illustrations  of  the 
system  design.  ADM  also  facilitates  the  development  of 
programming  requirements  and  design  documentation.  This  is 
normally  within  the  scope  of  a  design  methodology.  However, 
because  ADM  is  an  Ada-based  methodology,  there  is  a  tendency 
toward  using  the  Ada  language  as  much  as  passible  during  design. 
Also,  the  nature  of  the  Ada  language  requires  the  designer  to 
function  somewhat  like  a  chief  programmer  during  design.  For 
example,  the  designer  must  evaluate  the  overall  design  in  terms 
of  data  types,  overloading  of  functions,  etc.  Any  encumbrances 
created  by  improper  data  typing  or  improper  overloading  of 
functions  should  be  eliminated  before  actual  program  development 
begins.  ADM’s  use  of  Ada  as  a  PCI  for  developing  programming 
specifications  is  another  example  of  the  impact  and  use  of  the 
Ada  language  during  design. 

The  Ada  influence  on  ADM  moves  design  closer  to  the 
implementation/program  development  phase  of  the  traditional 
system  development  project  life  cycle.  Considering  this,  ACM 
broadens  the  scope  of  design.  However,  on  the  other  side  of  the 
project  life  cycle,  ABM  includes  seme  tasks  that  have 
traditionally  been  considered  within  the  scope  of  design. 

1.3. 3. 3  Outputs 

The  output  of  ADM  is  an  Ada  Design  Document.  Components  of  this 
document  are  listed  below: 

a.  System  Chart 

b.  Structure  Chart 

c.  Packages  Chart 

d.  N*  Chart 

e.  Ada  POL  expression  of  the  system 

f.  Traceability  Matrix 

g.  Design  Philosophy  Document 
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h.  logical  Data  Structures  Model 

i.  Jackson  Data  Structures. 

The  Ada  Design  Document  is  intended  to  provide  the  information 
necessary  for  implementing  the  design. 


1.4  BBCQMMBMDATIOMS  FOR  PI?R?pIlNBL  USING  AIM 


As  stated  earlier,  it  vas  assumed  that  the  requirements 
analyst  (s)  and  the  designer  (s)  are  not  the  same  person (s) . 
Therefore,  separate  recommendations  are  provided  below  for  each 
of  these  positions. 

1.4.1  acquirements  Analyst  Recommendations 

The  requirements  analyst  supplying  ABM  should  be  familiar  with 
the  Structured  Analysis  and  SADT  methodologies.  Ideally,  he  will 
have  experience  applying  one  of  these  methodologies.  It  is  also 
recommended  that  the  requirements  analyst  become  sufficiently 
familiar  with  selected  constructs  of  the  Ada  language  to  use  it 
as  the  basis  for  writing  structured  English  functional 
specifications . 

Of  course,  it  nay  not  always  be  possible  to  assign  a  requirements 
analyst  with  the  above  qualifications  to  a  development  project. 
Therefore,  some  requirements  analyst  training  recommendations  are 
provided  below: 

a.  Attend  a  Structured  Analysis  course  (e.g.,  a  week-long 
Yourdon  Structured  Analysis  course  or  a  Deltak 
Structured  Analysis  course) . 

b.  Develop  familiarity  with  SADT  (e.g.,  read  the  SADT 
articles  listed  in  Table  1.4. 1-1). 

c.  Develop  familiarity  with  the  Ada  language  (e.g.,  read 
the  sections  of  an  Ada  text  or  reference  manual  such  as 
the  ones  listed  in  Table  1.4. 1-1  that  relate  to  the 
constructs  used  by  ABM  to  express  function 
requirements) . 

1.4.2  Designer  Becommendations 

The  designer  applying  ADM  needs  a  "tool  bag"  full  of  design 
tools.  Knowledge  of  and/or  experience  working  with  four  design 
methodologies  is  needed  by  the  ADM  designer.  Additionally,  he 
should  understand  two  design  concepts  that  are  often  associated 
with  Ada  -  information  hiding  and  abstract  data  types.  Finally  a 
good  working  knowledge  of  Ada  is  necessary  in  order  to  use  Ada 
during  design. 
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Table  1.4. 1-1  Suggested  Training  Materials  and  Courses  Cor  ABM  and  ADM  Users. 


In  short,  the  ADB  designer  should  be  an  experienced,  state-of- 
the-art  software  engineer.  Bealizing  that  it  nay  be  difficult  to 
assign  such  a  designer  to  each  developaent  project,  two 
recoaaendations  for  training  an  ADB  designer  are  provided  below: 

a.  Attend  a  Tourdon  Structured  Design  course  or  a  software 
engineering  course  that  addresses  structured  design, 
object-oriented  design,  and  data-driven  design. 

b.  Attend  an  Ada  design  course. 

1.4.3  saatgss_fgi-5ia4i.3Bd.Iii.uiB3 

Table  1.4. 1-1  is  a  concise  list  of  courses,  books,  and  articles 
that  aay  be  appropriate  for  study  before  applying  AIB.  A 
bibliography  which  lists  all  of  the  books,  articles,  class 
outlines,  etc.,  accuaulated  during  the  study  is  attached  and  nay 
be  used  to  select  study  naterial  for  reguirenents  analysts  and 
designers  expected  to  use  AIB. 

1.5  SYBOPSIS  OF  SOCCmiSG  CHAPTEBS 

Chapter  2  describes  ABB  and  directs  the  reguirenents  analyst  in 
its  application.  Bach  conponent  of  ABB  is  described,  and 
nunerous  ex an pies  and  guidelines  are  provided  to  help  the 
reguirenents  analyst  apply  ABB. 

Chapter  3  is  devoted  to  ADB.  The  purpose  of  this  chapter  is  to 
provide  a  brief  description  of  ADB  and  direction  for  the  designer 
applying  it.  Again,  nunerous  exanples  and  guidelines  are 
provided. 

The  conplexity  and  power  of  Ada  reguires  careful  discretion  fron 
the  Ada  designer/progranner .  Therefore,  there  is  a  need  for  a 
set  of  Ada  developaent  standards.  Chapter  4  is  an  accuaulation 
of  Ada  developaent  standards  developed  during  the  Ada  Capability 
Study. 

Chapter  5  sunaarizes  the  nethodology  experiences  and 
reconnendations  that  evolved  during  the  study.  This  includes 
lessons  learned,  reconnendations  for  inproving  AIB,  and 
reconnendations  for  further  research. 
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CHAPTER  2 


ADA  REQUIREMENTS  METHODOLOGY  (ARM) 


2 . 1  PREFACE 

As  illustrated  in  Figure  1.3. 3-1,  ARM  converts  the  A- 
specifications  to  an  Ada  Requirements  Document  which  feeds  into 
the  design  process.  The  purpose  of  converting  the  A- 
specifications  to  another  document  is  twofold  -  (1)  to  restate 
the  A-specifications  as  structured,  organized  requirements  and 
(2)  to  effect  an  understanding  of  ihe  problem  which  can  be 
conveyed  to  the  designer. 

ARM  develops  system  requirements  in  four  parts  as  follows: 


Part  I 
Part  II 
Part  III 
Part  17 


Functional  Requirements 
Non-Functional  Requirements 
Concurrency  Requirements 
Ada  Requirements  Document 


Part  I  consists  of  four  major  tasks:  (1)  functionally  decompose 
the  problem  using  DFDs,  (2)  develop  a  logical  data  structures 
model,  (3)  develop  a  data  dictionary,  and  (4)  state  the 
functional  requirements.  The  other  three  parts  are  single-step 
parts.  Part  II  is  the  development  of  non-functional  requirements 
(i.e.,  requirements  relating  to  performance,  reliability, 
maintainability,  etc.).  Part  III  is  the  development  of 
concurrency  requirements  (charts  are  created  to  graphically 
illustrate  concurrency).  In  Part  17,  the  Ada  Requirements 
Document  is  compiled. 


It  is  recommended  that  the  parts  be  performed  in  order  (as  listed 
above).  Fiqure  2.1-1  illustrates  the  order  in  which  ARM  steps 
are  to  be  performed  with  concurrency  where  appropriate. 

2  •  2  f  SISIS 

Descriptions,  guidelines  and  examples  for  the  four  steps  of  Part 
I  are  provided  below. 

2.2.1  Functional  Decomposition  Model 


2.2. 1.1  Description 

The  Functional  Decomposition  Model  is  a  top-down  breakdown  of 
what  has  to  be  done  in  the  system.  The  tool  utilized  to  express 
it  is  a  directed  graph. 

The  major  elements  of  the  graph  are  boxes  which  represent 
functions  or  processes  which  must  be  accomplished,  directed  arcs 
which  represent  the  flow  of  data  or  control  information,  and 
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Figure  2.1-1  Model  for  Performing  Ada  Requirements  Methodology  Tasks. 
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circles  which  may  be  used  to  represent  files  or  temporary 
repositories  of  data.  The  side  cf  the  box  to  which  an  arc  is 
connected  has  significance  according  to  the  following  conventicn: 

Left  side  -  input  data  which  will  usually  be  consumed  or 
modified  by  the  function  or  process; 

Top  side  -  control  information  or  data  which  will  be  utilized 
to  control  the  function  or  process  but  will  not  normally  be 
altered; 

Bight  side  -  any  and  all  outputs  of  the  process  or  function 
which  may  then  be  used  as  input  or  control  for  any  process  or 
function/  or  as  an  output  of  the  diagram  of  which  this  box  is 
an  element; 

Bottom  side  -  is  not  strictly  a  data  flow  but  is  utilized  to 
reference  the  mechanism  by  which  a  particular  function  may  be 
implemented  such  as  a  piece  of  hardware,  or  a  particular 
software  function  or  utility;  these  are  not  normally 
indicated  until  late  requirements  analysis  or  early  design; 
accompanying  text  should  clarify  whether  this  implementation 
is  binding. 

The  graph  is  organized  into  diagrams  which  generally  have  3  to  7 
boxes  in  them.  The  structure  is  such  that  the  uppermost  diagram 
has  the  system  of  interest  as  cne  box  with  data  flow  arcs 
indicating  all  inputs  and  outputs  to  it  (see  Figure  2.2. 1-1). 

The  next  level  diagram  represents  the  functional  decomposition  of 
the  system  of  interest  into  its  major  functions.  This  is 
illustrated  by  Figure  2. 2. 1-2.  A  correspondence  should  be 
maintained  between  the  inputs  and  outputs  to  a  box  and  the  inputs 
and  outputs  to  the  diagram  which  represents  the  functional 
decomposition  of  that  box  so  that  no  flows  disappear  or  appear 
without  explanation.  This  structuring  of  diagrams  should  be 
carried  out  in  a  fashion  similar  to  the  construction  of  SADT 
Actigrams  or  the  leveling  of  a  data  flow  diagram  in  Structured 
Analysis.  A  numbering  scheme  should  be  followed  along  the  lines 
of  that  used  in  SADT. 

The  functional  decomposition  mcdel  is  the  major  element  of  the 
requirements  phase  representation  of  the  system.  All  other 
elements  are  directly  or  indirectly  related  to  it  and  should  be 
cross-referenced  to  individual  parts  of  it  when  feasible. 

2. 2. 1.2  Guidelines 

(a)  diagram  A-0  shows  environment  in  which  the  system  of 
interest  resides;  must  show  all  inputs  and  outputs  for 
the  system  of  interest. 

(b)  diagram  AO  shows  the  whole  system  of  interest;  must 
reflect  all  inputs  and  outputs  shown  in  A-0,  and 
generally  divides  the  system  into  3-7  major  logical 
components. 


(c)  each  diagram  reflects  all  inputs  and  outputs  shown  for 

its  corresponding  box  in  the  next  higher  diagram;  it 

generally  divides  its  process  into  3-7  subprocesses. 

(d)  elements  of  diagrams: 

(1)  boxes  -  represent  processes  or  functions;  should  be 
named  with  a  concise,  meaningful  statement  of  their 
function;  their  numbers  are  constructed  by 
assigning  a  unique  digit  to  each  box  in  a  diagram 
then  appending  each  digit  to  the  number  for  that 
diagram  (as  a  general  scheme  numbering  is  assigned 
top  to  bottom,  left  to  right) 

(2)  directed  arcs  -  represent  data  or  information; 
should  be  named  with  a  concise,  meaningful 
statement  of  their  content;  their  numbering 
reflects  the  box  they  connect  to  and  is  formed  by 
appending  a  prefix  to  a  box  number  to  indicate 
which  side  of  a  box  they  connect  to,  many  data 
flows  will  have  several  numbers  assiciated  with 
them 

(3)  circles  -  represent  files  or  temporary  repositories 
of  data;  these  should  be  given  unique  numbers  for 
the  entire  system;  files  should  be  introduced  at 
the  level  where  they  have  an  interface  with  more 
than  one  box 

(4)  small  circles  -  may  be  utilized  for  on-diagram 
connectors  when  a  data  flow  arc  would  otherwise 
have  to  cross  several  other  data  flows;  they  should 
have  unique  numbers  to  distinguish  them  when 
several  occur  on  the  same  diagram 

(5)  mechanism  arcs  -  short  arcs  connected  to  the  bottom 
of  boxes  represent  a  mechanism,  implementation, 
utility,  or  common  function;  should  be  named  with  a 
concise,  meaningful  statement  of  what  they 
represent;  when  representing  a  common  function  a 
list  of  equivalent  boxes  enclosed  within 
parentheses  is  an  appropriate  label. 

(e)  numbering  scheme: 

(1)  letter  portion: 

&  =  activity,  function,  process 
I  =  input  ' 

C  =  control 
0  =  output 

N  =  mechanism,  implementation 
D  =  data 
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(2)  nuaber  portion  -  each  digit  corresponds  to  the 
respective  level  of  the  structure  and  indicates  to 
which  eleaent  of  that  level  it  belongs 

(3)  foraation  -  each  box  in  the  graph  has  its  own 
unigue  nuaber;  each  diagraa  uses  the  nuaber  of  the 
box  that  it  expands  (except  the  overview  diagraa 
which  has  no  corresponding  box  and  is  therefore 
nuabered  A-0)  ;  each  data  itea  may  be  given  its  own 
unigue  nuaber  but  will  be  cross-referenced  to  a 
coaposite  nuaber  indicating  the  box  prefixed  by  a 
use  indicator  for  the  data  flows  in  which  it 
occurs. 


Figure  2.2. 1-1  Interface/Envircnment  System  flodel  (Diagram  1-0) 
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Figure  2.2. 1-2  Major  Functions  Model  (Diagras  10) 


2.2.2  fiaiuisiis sau 

2.2.2. 1  Description 

The  data  dictionary  is  a  textual  listing  of  the  iteas  which  flow 
along  the  data  flow  arcs  of  the  functional  Decomposition  graph. 

The  entries  should  be  recorded  with  neaningful  names  and  cross-* 
referenced  to  the  respective  diagraas.  Bspbasis  should  be  on 
logical  structure.  The  logical  structure  of  a  composite  data 
itea  aay  be  shown  using  the  Structured  Analysis  data  dictionary 
concepts  of  seguence,  repetition,  and  selection. 

The  data  dictionary  lists  all  the  logical  components  of  the  data 
flows  that  are  used  in  the  diagraas  of  the  Functional 
Decoaposition.  It  provides  the  information  for  the  development 
of  the  Logical  Data  Structures. 

2. 2. 2. 2  Guidelines 

1.  Seguence: 

D24 1  Hessage  Control  Block  *  header  info 
01124  ♦  tine  of  entry 

*  tine  of  delivery 

2.  Bepetition:  "<a>  (...)"  to  indicate  a  specific 

nuaber  of  repeats 
M<a|b|c| »  to  indicate  a 

variety  of  specific  number 
of  repeats 

**<a..b>  (...)  N  to  indicate  a  range 
of  possible  nuaber  of 
repeats 

default  a  *  1,  b  »  infinite  "<..>(...) " 

D23114  Routing-Indicator  -  B  *  <6>  (any-letter) 
111321 

3.  Selection: 

or  n[a..b]"  to  indicate  one  value  in  a 
range  of  values 

D23112  Hessage  Precedence  *  [critic! ECPJ Flash | 
1121231  Iaaediate | Priority | Boutine  ] 

4.  Options  "(...)" 

5.  Iteas  to  record  for  each  entry: 

a.  Data  Beference  Nuaber:  D12... 

b.  Name:  SOHE-NAHE 

c.  Coaposition:  =  ...  (when  applicable) 

d.  Values  and  oeanings:  (when  applicable) 


22 


«.  Belated  Cata  flows:  I1I241,  01*243 

6.  Coaaents  aay  be  denoted  by  enclosing  them  within 
asterisks. 


1.  BCUTING-INDICATCB  =  BI-CODE  ♦  TT-CODB 

BI-CODE  *  <1..7>  (ALPHABETIC  CHABACTEBS) 

TT-CODB  =  [ MESSAGE  SWITCH | 

DIBECT  TEBHINAI  EQUIPHENTI 
AOTOCIB  EACK80NE | 

AOIOCIB  HOB-BACKBONE] 

2.  THUNK-TYPE  =  TT-CCDE  ♦  COHHUNITY-CCDE 

TT-CODE  =  *SBE  1T-C0DE  ABOVE* 

CCHHDBITY-CODE  *  [Y|H|0] 

* Y  =  INTELLIGENCE* 

*B  *  STBATEGIC* 

*U  »  TACTICAL* 

3.  LINB-NOHBEB  =  LN-CCDE  ♦  LINE-STATUS  ♦  TT-CODE 
LN-CODE  »  [1|2|3|...|50] 

LINE-STATUS  *  IILI-CODE  ♦  BUSY-CODE  +  AVAIL* ELE-CCCE 

IELE-CODE  *  [1(0]  *1  =  TBUE,  0  *  FALSE* 
BUSY-CODE  *  [1|0]  *1  »  TBUE,  0  *  FALSE* 

AVAIL A ELS- CODE  *  [1|0]  *1  *  TBUE,  0  =  FALSE* 

TT-CODE  *  *SEE  1T-CCDB  ABOVE* 


Figure  2. 2. 2-1  Data  Dictionary  Entries  for  Three  Logical 

Data  Structures 
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2.2.3  iflaicai-Iaia-Sisasiaiss 

2.2.3. 1  Description 

1  logical  data  structure  aodel  is  a  graphic  representation  of  the 
logical  data  coaponents  of  the  nev  systea  and  their  relationships 
to  each  other,  as  perceived  by  the  reguireaents  analyst.  The 
word  "logical"  iaplies  that  the  structure  is  net  physical. 
However,  the  logical  data  structures  aodel  developed  in  the 
reguireaents  phase  is  intended  to  be  a  priaary  input  to  the 
designer  when  he/she  deteraines  the  physical  data  structures  for 
the  new  systea. 

1  logical  data  structures  aodel  is  caaposed  of  the  following: 

a.  logical  data  coaponents 

b.  Keys  for  accessing  each  coaponent 

c.  Relationships  (in  the  fera  of  pointers)  between  the 
coaponents. 

The  aodel,  along  with  the  data  dictionary,  which  describes  the 
contents  of  each  logical  data  coaponent,  provides  the  designer  an 
excellent  view  of  the  data  structures  required  by  the  systea. 

Rith  this  inforaation,  the  designer  Bust  deteraine  the  physical 
data  structure  (s)  (e.g.  hierarchical  data  base,  randoa  access 
file,  FIFO  gueue,  stack,  etc.)  needed  for  the  new  systea. 

2. 2. 3. 2  Guidelines 

a.  Identify  all  the  file  accesses  in  the  existing  systea 
and  group  thea  into  input  and  output  categories. 

b.  Identify  the  key  for  each  access. 

c.  Analyze  each  input  and  cutFut  access  in  teras  of  the 
data  flow  that  is  actually  required  versus  the  present 
data  flow. 

d.  Develop  logical  coaponents  for  the,  reguired  data  flows. 

e.  Analyze  each  logical  coaponent  in  teras  of  each 
relationship  to  the  key  and  separate  unrelated  data 
eleaents  (into  separate  logical  coaponents) . 

f.  Separate  repeating  groups  into  new  logical  coaponents. 

g.  Deteraine  relationships  (pointers)  between  all  the 
logical  coaponents  developed. 

h.  Develop  a  aodel  of  the  logical  data  structures. 

Figure  2. 2. 3-1  illustrates  a  possible  physical  file  structure  for 
an  existing  aessage  switch  systea  that  is  to  be  replaced  or 
redesigned.  In  this  exaaple,  all  data  eleaents  are  coabined  into 
one  data  structure.  Figure  2. 2. 3-2  illustrates  bow  a 


requirements  analyst  might  represent  snch  a  file  structure 
logically  during  the  reguirenents  phase  of  a  project  to  redesign 
the  aessage  switch  systen. 

In  order  to  coae  up  with  the  logical  data  structure  in  Figure 
2. 2. 3-2,  the  reguireaents  analyst  would  analyze  the  data  flow 
requirements  for  each  access  to  existing  file  structures.  Based 
upon  the  analysis  of  the  current  file  structure,  new  logical  data 
structures  (consisting  of  only  the  data  elements  required  for 
each  access)  would  be  developed.  Then  these  initial  logical  data 
structures  would  be  evaluated,  refined,  and  aodeled. 
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TRUNK  TIPE 

LINE  NC. 

LINE  STATUS 

81(1) 

11(1) 

18(1) 

LS  (1 ) 

BI(1) 

TT  (1) 

LR  (2) 

LS  (2) 

HI  (2) 

TT  (2) 

LB  (3) 

LS(3) 

81(3) 

TT  (1) 

18(1) 

IS  (1 ) 

RT  (3) 

TT  (1) 

LN  (2) 

LS  (2) 

81(4) 

TT  (3) 

LN<4) 

IS  (4) 

81  (4) 

• 

• 

TT  (4) 

m 

18(5) 

• 

• 

LS  (5) 

• 

• 

• 

• 

81  (n) 

• 

• 

• 

TT  (n) 

• 

• 

LN  (n) 

• 

• 

LS  (n) 

Figure  2. 2. 3-1  Possible  physical  file  structure  for  an 

existing  aessage  switch  system 
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Explanation:  Data  structure  components  are  represented  by 

boxes  which  are  divided  into  two  parts  - 
(1)  leftmost  part  represents  the  logical  component 
and  (2)  rightmost  part  represents  the  key  cf  each 
logical  ccvpcnent. 

Relationships  (pointers)  between  data  structures  are 
represented  by- directed  arcs. 

♦Logical  Components  -  Routing-Indicator  (BI-code.TT-code) 

-  Trunk-Type  (TT-code,LH-code) 

-  Line-Huater  (IN-code, Line-status, TT-code) 

♦Keys  are  SD^fSliQed  for  each  logical  component. 

Figure  2. 2. 3-2  i  logical  data  structures  model  of  the  physical 

file  structure  illustrated  by  Figure  2. 2. 3-1. 


2.2.4  A&-ZjI&S&i2&fll_£e3!li£§JS&£s 

2.2.4. 1  Description 

The  Ida  Functional  acquirements  use  Ada  language  constructs  along 
with  entry  nases  froa  the  Data  Dictionary  to  express  structured 
descriptions  of  the  functions  to  be  accomplished  by  processes 
that  appear  on  the  lowest  level  diagraas  of  the  Functional 
Decoaposition.  The  purpose  for  using  Ada  notation  to  express 
reguireaents  is  to  provide  a  standard  aediua  for  coaaunicaticn 
that  will  provide  a  clear,  concise,  and  non-ambiguous  statement 
of  reguireaents. 

2. 2. 4. 2  Guidelines 

a.  Dse  the  following  peraissible  Ada  constructs: 

1)  if -statement 

2)  case-statement 

3)  loop-statement 

4)  assignment-statement 

5)  code-stateaent 

6)  expression 

7)  relation 

8)  exit-statement 

9)  procedure  calls  fcr  pre-defined  procedures 

10)  raise-statement 

11)  exception-handler 

b.  Use  Data  Dictionary  entry  naaes  with  above  Ada 
constructs  to  express  reguireaents. 

c.  Hhen  above  constructs  are  insufficient  to  express 
reguireaents,  use  a  disciplined  English  stateaent 
preceded  by  " — >M. 

d.  Do  not  use  a  declaration;  all  items  should  appear  in  the 
Data  Dictionary. 

e.  For  explanative  comments  use  a  comment  in  an  Ada  format 
(i.e.,  preceded  by  " — ") . 

See  Figure  1.3. 2-1  for  an  example  of  Ada  functional  requirements. 
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2  •  3  £A£2.II.=.£2jHXJ!fi£I22!!11.2££j££2£m£ 

2.3.1  £5£££i£liJ2£ 

Oftentiaes  the  functional  regnireaents  of  a  systea  receive  so 
aoch  attention  that  the  non-functional  reguireaents  are 
neglected.  However,  certain  ncn-f unctional  reguireaents  can 
significantly  iapact  the  design  of  a  systea.  Soae  of  the  types 
of  non-functional  reguireaents  tc  be  considered  and  stated  in  the 
reguireaents  docuaent  are  (1)  perforaance,  (2)  reliability,  (3) 
security,  and  (4)  operating  constraints,  in  excellent 
description  of  non-functional  reguireaents  is  found  in  the  paper, 
•SOFTBABE  BECUIBIBBHTS:  i  BEPOBT  ON  THE  STATE  OF  THE  ART". 

2.3.2 

a.  Identify  all  the  non-functional  reguireaents  of  the 
systea  that  could  iapact  design. 

b.  list  each  non-functional  reguireaent  identified  in  a 
separate  section  of  the  reguireaents  docuaents. 

c.  Use  the  article,  "SOFTWARE  HEQUIBEBEMTS:  A  REPORT  ON  THE 
STATE  OF  THE  ART"  pp  22-30,  leh,  Zave,  Conn,  S  Cole. 

This  article  is  Technical  Beport-949  and  was  published 
by  the  University  of  Baryland  in  October  1980. 


2 . 4  ££I-U  SMASH  IBIS 

2.4.1  CiSC£ie£isn 

ihen  concurrency  is  required  in  the  specification  it  should  be 
separated  out  and  specifically  stated  in  this  portion  of  the 
requirements  document.  Any  related  requirements  that  will  assist 
the  designer  in  making  decisions  about  how  the  concurrency  would 
best  be  implemented  should  also  be  included  in  this  portion  even 
though  they  may  also  appear  elsewhere.  This  may  include  such 
information  as  how  many  items  must  be  processed  simultaneously, 
or  the  rate  at  which  items  may  enter  or  depart  the  system,  or 
minimum  and  maximum  response  time  required  of  specific  processes. 
This  data  will  greatly  assist  a  designer  when  he  is  determining 
the  best  mechanism  to  use  for  concurrency  in  this  particular 
case. 

When  the  concurrent  operations  required  in  the  system  are  non¬ 
trivial,  then  a  concurrency  model  is  introduced.  The  tool 
utilized  to  express  it  is  a  directed  graph  similar  to  the  B-net 
used  with  Software  Beguirements  Engineering  Methodology  (SBEN) . 
This  is  composed  of  boxes  to  represent  the  processes  or 
functions,  directed  arcs  which  indicate  flow,  and  circles  with 
special  symbols  at  junctions. 

2.4.2  Guidelines 

a.  When  feasible  function  names  should  correspond  to  names 
used  in  the  functional  decomposition  model. 

b.  only  include  processes  of  interest  to  the  concurrency 
viewpoint  in  the  concurrent  model. 

c.  Segregate  the  concurrency  model  from  the  functional 
decomposition  model. 

d.  The  special  symbols  tc  be  used  in  junction  circles  are 
the  following: 

&  -  "and",  these  circles  will  have  one  input  arc 

and  multiple  output  arcs;  they  represent 
initiation  cf  concurrent  execution  flows. 

I  -  "or",  these  circles  will  have  one  input  arc 
and  multiple  output  arcs;  they  represent  a 
selection  among  non-concurrent  flows. 

+  -  "reunion",  these  circles  will  have  multiple 

input  arcs  and  one  output  arc;  they  will 
represent  the  convergenr  of  differing 
execution  flews  and  in  t.  case  of  concurrent 
input  flows  indicate  that  •_  1  flows  must  reach 
this  point  before  the  resulting  flow  may 
start. 
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letters  -  "exclusion”,  these  circles  will  occur  in 
pairs  designated  by  a  specific  letter  for  each 
pair;  the  first  of  the  pair  will  have  nultiple 
inputs  and  will  signify  that  only  one  flow  can 
proceed  through  the  following  processes;  the 
second  of  the  pair  will  have  multiple  outputs 
signifying  that  the  appropriate  flow  can 
proceed  and  that  another  flow  nay  proceed 
through  the  enclosed  processes. 

fihen  there  is  more  than  one  area  in  which  concurrency  is 
an  issue  use  separate  concurrency  models  to  express 
thee. 

If  a  concurrency  nodel  is  too  complex  then  leveling 
similar  to  that  utilized  in  the  functional  decomposition 
model  may  be  used  to  structure  the  concurrency  model 
into  understandable  pieces. 


u)wi»  I  nq  wr  on  ioc  hot  mouixzz 
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2.5  PART  IV  ~  ADA  REQUIREMENTS  PQCUHBNT 

2.5.1  Description 

The  Ada  Requirements  Document  is  primarily  the  compilation  of  the 
outputs  from  each  previous  phase  of  the  requirements  phase.  It 
is  the  mechanism  through  which  the  requirements  analyst's 
understanding  of  the  problem  is  to  be  conveyed  to  the  designer. 

2.5.2  Guidelines 

a.  Write  a  brief  description  of  the  problem  (system)  that 
was  studied  during  the  requirements  phase.  Give  reasons 
why  the  present  system  (if  there  is  one)  needs  to  be 
changed. 

b.  Organize  the  Ada  Requirements  Document  according  to  the 
outline  below: 

I.  SYSTEM  OVERVIEW 

A.  Brief  Description  of  System  Studied 

B.  Reasons  for  Study 

II.  FUNCTIONAL  SPECIFICATIONS 

A.  Environment  Data  Flow  Diagram  (A-0) 

B.  Data  Flow  Diagram  of  All  Major  Functions  of 
the  System  (A-0) 

C.  Data  Flow  Diagrams  and  Ada  Requirements 
Specifications  for  Each  Major  Function  of  the 
System 

D.  Data  Dictionary 

E.  Logical  Data  structures  Model 

III.  NCN-FONCTICNAL  REQUIREMENTS 

IV.  CONCURRENCY  REQUIREMENTS  -  CHARTS 


CHAPTER  3 


ADA  DBS IGN  METHODOLOGY  (ADM) 


3 . 1  £RE| ACE 

Hithin  the  system  development  life  cycle,  the  design  phase 
prodaces  a  detailed  approach  to  solving  the  problem  characterized 
by  the  requirements  phase.  The  design  phase  itself  consists  of 
three  parts:  architectural  design,  detailed  design,  and 
compilation  of  the  Ada  Design  Document.  Given  the  Ada 
Requirements  Document,  which  is  the  output  of  the  requirements 
phase,  as  input,  the  architectural  design  step  produces  the 
following  items  to  be  used  as  input  to  the  detailed  design  phase: 

a.  a  graphical  representation  of  the  system  structure 
(modified  structure  chart) 

b.  system  flowchart 

c.  N2  chart 

d.  packages  chart 

e.  data  structure  charts 

f.  Ada  unit  specifications. 

Furthermore,  the  architectural  design  must  be  correct  (every 
requirement  listed  in  the  requirements  document  is  satisfied) , 
and  good  (it  should  be  maintainable,  efficient,  etc.) .  The 
former  criteria  can  be  approached,  in  part,  by  using  a 
traceability  matrix  that  maps  requirements  into  modules  in  the 
architectural  design.  The  standard  metrics  for  goodness  are 
coupling  and  cohesion. 

The  steps  to  be  followed  during  architectural  design  are 
described  in  detail  in  subsequent  sections.  The  order  of  the 
architectural  design  steps  is: 

a.  Develop  data  structures  for  all  the  files,  data  bases, 
and  intermediate  data  repositories  required  by  the 
system 

b.  Perform  an  object-oriented  design  pre-analysis 

c.  Develop  concurrency  requirements  for  the  system 

d.  Generate  a  structure  chart 

e.  Validate  the  goodness  of  design  by  applying:  an 
analysis  of  coupling,  an  analysis  of  cohesion,  an'd  a 
post-analysis  of  the  packaging 
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f.  validate  the  correctness  of  design  by  constructing  a 
traceability  matrix  to  link  each  requirement  with  the 
Ada  design  unit  responsible  for  its  implementation 

g.  Create  an  N*  chart  based  on  the  data  flow  interfaces 
between  the  functions  on  the  structure  chart 

h.  Perform  a  preliminary  design  review  and  iterate  any 
combination  of  the  steps  above  as  required 

i.  Develop  Ada  unit  specifications  for  each  Ada  design  unit 
of  the  structure  chart 

j.  Perform  hardware/software  partitioning  of  the  system. 

Detail  design  produces  an  Ada  representation  of  the  architectural 
design.  Once  the  Ada  representation  of  the  system  is  completed, 
the  design  is  verified  and  traced  back  to  the  system  requirements 
(Ada  Bequirements  Document) . 

The  steps  of  detail  design  are  described  in  subsequent  sections. 
The  order  of  the  detail  design  steps  is: 

a.  Express  the  system  design  in  Ada  PDL 

b.  Perform  a  final  design  review  which  consists  of  the 
following: 

1.  Design  Walk-Thru 

2.  Preprogramming  Ada  Evaluation 

3.  Heguireaents-To-Cesign  Traceability 

4.  Design  Philosophy  Review 

Compilation  of  the  Ada  Design  Document  is  the  third  and  final 
part  of  design.  This  phase  consists  of  organizing  all  the  design 
outputs  into  a  formal  document. 

The  sections  that  follow  give  guidance  for  applying  the 
architectural  and  detail  design  steps  listed  above.  However,  the 
guidance  provided  is  somewhat  general,  and  before  applying  ADM, 
the  designer  should  read  the  description  of  ADM  and 
recommendations  for  personnel  applying  ADM  in  Chapter  1 
(INTRODUCTION  TO  AIM)  . 


3 . 2  ASCMI21C2U Eli.IIS I G]| 

3.2.1  Data  Structure  Chart 

3.2.1  .1  Description 

All  data  structures  of  the  systen  will  be  described  using  the 
Jackson  structure  diagraas.  The  graphical  presentation  of  a  data 
structure  diagran  aay  very  well  provide  a  basis  for  subsequent 
packaging  thus  eaphasis  should  be  placed  on  the  precise 
documentation  of  data  structures  using  the  Jackson  structure 
diagraa. 

The  Jackson  nethod  recognizes  three  coaposite  types  when 
representing  data  structures: 

a.  Sequence  structure 

b.  Selection  structure 

c.  Iteration  structure 

and  one  elementary  coaponent  (no  further  decoapositicn  possible) . 

Elementary  components  will  be  at  the  leaf  nodes  of  the  structure 
diagraa  and  composite  components  will  be  at  non-leaf  nodes. 
Selection  is  represented  by  the  small  circle  (o)  in  the  upper 
right  corner  of  a  box  and  iteration  by  an  asterisk  (*)  in  the 
upper  right  corner.  Consider  Figure  3.2. 1-1  which  depicts  a 
stack  having  elements  consisting  of  two  parts  -  a  type  (1,  2,  or 
3)  and  an  integer  value: 

As  an  extension  to  the  Jackson  approach  we  introduce  the  symbol 
plus  (+)  to  indicate  one  or  more  occurrences  of  a  coaponent. 

Thus,  in  the  prior  example,  if  the  semantics  did  not  permit  an 
empty  stack  we  would  have  used  the  plus  sign  (see  Figure  3.2. 1-2) 
instead  of  using  an  asterisk. 

3. 2. 1.2  Guidelines 

Each  logical  data  structure  developed  from  the  requirements  phase 
should  be  re-examined  and  the  appropriate  Jackson  structure 
diagraas  generated.  (Normally  one  structure  diagraa  for  each  of 
the  significant  logical  data  structures.)  fihen  appropriate  (e.g., 
a  class  of  similar  data  structures) ,  several  data  structures  may 
be  characterized  in  one  diagram.  Also,  as  additional  data 
structures,  files  or  databases  are  introduced  in  the  design 
phase,  the  designer  should  modify  the  logical  data  structures 
model  produced  during  the  requirements  phase  and  describe  each 
new  structure  with  an  appropriate  Jackson  structure  diagraa. 

Jackson  Figures  3.2. 1-3,  3. 2. 1-4,  and  3.2. 1-5  illustrate  the 
application  of  this  approach  with  a  logical  data  structure  from  a 
requirements  document,  a  file  description  and  a  relational 
database  description  respectively. 
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Elementary  components :  1,  2,  3,  VALUE 

Sequence :  TYPE  followed  by  VALUE 
Selection:  1  or  2  or  3  under  TYPE 

Iteration:  ELEMENT  occurs  0  or  more  times  under  STACK 


Figure  3.2. 1-1  Examples  of  the  Jackson  symbolism 


— a 

Element 


Occurs  zero  or  aore 

Class 


Occurs  ons  or  aors 

Class 


Figure  3. 2. 1-2  Extension  to  symbolism  to  Incorporate  an  Iteration 
with  at  least  one  occurrence. 
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Consider  the  following  deta  structure  (logical)  representation 
enanatlng  from  the  ABM  document : 


ROUTING- INDICATOR  -  RI-CODE  +  TT-CODE 
BI-CODE  -  <1 . .  7X ALPHABETIC  CHARACTERS) 

TT-CODE  -  [MESSAGE  SWITCH  {  DIRECT  TERMINAL  EQUIPMENT  |  AUTODIN 
BACKBONE  |  ADTODIN  NON-BACKBONE] 


Figure  3. 2. 1-3 


Transformation  from  requirements  logical  structure 
to  Jackson  structure  diagram. 


3.2.2  £l£z&J3al£Si£.JL££2i2i£S-£fc.j§££r2£iSn£§d.£§§i2n 

3.2.2. 1  Description 

Information  hiding  and  abstract  data  types,  both  supported  by 
Ada,  are  powerful  design  concepts  used  to  achieve  a  high  degree 
of  eodule  independence  and,  hence,  maintainability.  Because  cf 
the  significance  of  this  concept,  this  methodology  employs  two 
phases  to  identify  appropriate  abstract  types  or  inf creational 
strength  modules  (packages) .  The  first  phase  is  a  pre-analysis 
of  the  reguirements  and  is  object  oriented.  The  second  phase  is 
a  post-analysis  of  the  functional  decomposition  and  attempts  to 
identify  informational  strength  modules.  While  the  pre-analysis 
does  not  drive  the  functional  decomposition  it  certainly  can 
influence  the  decomposition  approach  and  provide  checks  and 
balances  for  the  design  decisions  that  are  made  (i.e.,  if  a 
functional  decomposition  is  made  that  potentially  violates  the 
object  oriented  packaging,  that  particular  decision  should  be 
reviewed  and  justified).  In  that  sense,  the  object  oriented  pre¬ 
analysis  is  used  as  a  guideline  or  map  for  the  post-analysis 
steps  that  are  applied  to  each  iteration  of  the  functional 
decomposition.  The  pre-analysis  follows  the  approach  outlined  by 
Grady  Booch. 

3.2. 2. 2  Guidelines 

As  stated  above,  this  step  (pre-analysis)  is  object-oriented.  An 
object  is  an  identifiable  entity  or  item  within  the  system  which 
possesses  attributes  (characteristics) .  Generally  objects  are 
data  structures  (e.g.  files,  data  bases,  stacks,  queues,  etc.)  or 
hardware  components  (e.g.  screens,  keyboards,  ports,  etc.)  around 
which  operations  are  performed.  Tor  example,  a  payroll  master 
file  might  be  an  abject  in  a  payroll  system.  Attributes 
associated  with  a  file  include  file  name,  size,  and  organization. 
Operations  around  a  file  include  open,  close,  read,  write,  and 
update. 

The  steps  of  pre-analysis  are  provided  below  in  the  order  that 
they  are  to  be  performed. 

a.  Develop  an  informal  strategy  for  abstracting  the  problem 

solution  environment. 

b.  Formalize  the  strategy. 

1.  Define  the  objects  of  the  system  using  a  Jackscn- 
like  structure  model. 

2.  Define  the  attributes  of  the  objects. 

3.  Define  the  operations  on  each  object  in  the  system. 

4.  In  a  bottom-up  fashion  collect  common  operations 
around  objects  in  the  system  and  form  packages. 
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c.  Evaluate  critical  operations  defined  in  the 

reguireaents.  for  exaaple,  if  a  performance  constraint 
in  reguireaents  is  critical,  the  designer  night  want  to 
prototype  one  or  sore  of  the  key  packages,  i  key 
package  is  intended  to  aean  a  package  in  which  critical 
operations  are  encapsulated. 

The  identification  of  potential  packages  early  in  design  (during 
the  first  step)  provides  flexibility  for  independent  developaent 
of  najor  components  (packages)  of  the  system.  Of  course,  this  is 
a  deviation  from  top-down  developaent. 

3.2. 2. 3  Exaaple 

Consider  the  problem  of  developing  a  page  editor  for  a  small, 
personal  computer.  The  systea  has  a  diskette  used  to  hold  the 
file  to  be  edited;  a  monitor  for  displaying  a  page  of  the  file  tc 
be  edited;  a  keyboard  for  inputting  characters,  single  character 
coaaands,  and  character  strings  for  updating  the  file  page;  and, 
of  course,  the  processor.  A  formal  reguireaents  docuaent  would 
enuaerate  the  different  editing  operations  and  real-tiae 
constraints  for  the  proposed  systea. 

The  steps  of  object-oriented  design  as  applied  to  these 
reguireaents  are  depicted  in  figures  3. 2. 2-1,  3. 2.2-2,  3. 2. 2-3, 
and  3. 2. 2-4. 
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Figure  3. 2. 2-3  Attributes  and  operations  assigned 


3.2.3  £onsa£E§SSI 

3.2.3. 1  Description 

Concurrency  is  reflected  in  two  ways  in  the  architectural  design 
phase: 

a.  In  the  structure  chart 

b.  In  the  concurrency  chart. 

The  structure  chart  describes  the  decomposition  cr  structure  of 
the  system  including  the  various  types  of  tasks  and  interprocess 
coaaunication.  Parallelograms  indicate  tasks  and  solid/dashed 
lines  indicate  communication  with  tasks.  The  concurrency  chart 
shows  flow  of  control  and  synchronization  constraints.  The 
latter  chart  should  be  developed  as  the  next  step  after  the  pre¬ 
analysis  object-oriented  design. 

This  final  document  uses  the  same  symbology  developed  in  the 
requirements  phase  and  should  be  used  to  expand  the  concurrency 
chart  by  adding  concurrency  developed  in  the  design  phase  with 
that  developed  in  the  requirements  phase.  Concurrency  in  the 
design  phase  may  be  introduced  to  enhance  program  understanding, 
simplify  the  design,  or  respond  to  certain  requirement 
constraints.  In  the  requirements  phase,  concurrency  was 
introduced  only  when  it  modeled  the  problem  environment  (i.e., 
only  when  it  was  itself  a  constraint  of  the  system) . 

3. 2. 3. 2  Guidelines 

The  sequence  in  which  the  data  describing  concurrency  is 
generated  is  important  and  should  be  as  follows: 

a.  Determine  concurrency  that  may  be  added  to  that  already 
described  in  the  requirements  phase.  This  "design" 
concurrency  is  introduced  in  the  following 
circumstances : 

1.  When  the  design  will  be  clearer  by  its  introduction 

2.  When  it  is  essential  to  meeting  a  performance 
requirement  of  the  system. 

b.  Augment  the  concurrency  charts  developed  in  the 
requirements  phase  as  necessary  to  introduce  the 
"design"  concurrency. 

c.  From  the  new  concurrency  charts,  tasks  will  be 
identified  that  will  subsequently  appear  as 
parallelograms  in  the  system  structure  chart. 

d.  Determine  task  activation  requirements  to  be  shown  by 
dashed  lines  in  the  system  structure  chart. 


Guidelines  for  development  of  the  structure  chart  are  qiven  in 
Section  3.2.4. 


Refer  to  the  requirements  section  for  an  example  of  the 
construction  of  a  concurrency  chart. 


3.2.4  $ysteji_§trugture. Ch§r t 

3. 2. 4.1  Description 

A  structure  chart  illustrates  the  functional  hierarchy  and 
interfaces  (flow  of  data)  between  the  functions  of  the  systen. 

It  is  initially  developed  froa  the  EFDs  produced  during  the 
requirements  phase  and  iteratively  aodified  until  the  optinua 
systea  structure  is  achieved.  The  purpose  of  the  structure  chart 
is  to  be  used  as  a  tool  for  developing  a  solution  to  the  problem 
studied  during  the  requirements  phase. 

Once  the  first-cut  structure  chart  is  completed,  the  structure 
chart  serves  as  a  worksheet  for  iteratively  studying  and 
modifying  the  system  structure.  The  goal  is  to  modify  the  first- 
cut  structure  chart  until  optimum  coupling,  cohesion,  packaging, 
and  information  hiding  is  achieved. 

In  addition  to  the  traditional  modules  that  are  represented  on 
the  hierarchy  chart  by  rectangular  boxes,  it  is  recommended  that 
tasks  (parallel  execution  processes)  be  represented  by 
parallelograms.  These  parallelograms  are  to  be  incorporated  in 
the  hierarchy  or  structure  charts  parallel  to  the  invoking 
module.  Osing  this  notation  we  can  easily  represent  the  tasks 
that  may  be  executed  in  parallel. 

3. 2. 4. 2  Guidelines 

A  variety  of  tools  have  been  used  to  produce  a  hierarchical 
structure  of  the  computing  system  including  functional 
decomposition,  information  hiding,  Jackson  methodology  and 
structured  design  methodology  among  others.  These  approaches 
have  been  successfully  documented  on  a  variety  of  problem  types. 
Each  approach  or  method  has  individual  advantages  and 
disadvantages.  ADM's  approach  is  that  of  a  toolbag,  that  is, 
utilize  the  approach  that  appears  most  useful  for  the  problem  at 
hand.  However,  rather  than  just  reach  into  the  toolbag,  the 
designer  should  first  attempt  a  decomposition  based  on  the 
Tourdan/Constantine  approach  cf  structured  design  that  is  driven 
by  a  data  flow  diagram.  This  will  permit  the  utilization  of 
objects  resulting  from  the  requirements  phase  and  provide  a 
continuous  approach  across  life  cycle  phases.  Thus,  the 
guidelines  below  will  direct  the  major  attention  to  the 
structured  design  approach  with  emphasis  directed  to  the  other 
approaches  in  a  secondary  manner. 

There  are  two  major  strategies  for  deriving  a  structure  chart 
during  design:  (1)  transform  analysis  and  (2)  transaction 
analysis.  The  steps  for  implementing  each  of  these  strategies  is 
provided  below: 

a.  Transform  Analysis  steps 

1.  Step  1  -  Develop  an  expanded  data  flow  diagram 

(EFD)  from  all  the  lowest  level  diagrams  produced 
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during  the  requirements  phase.  Simply  connect  all 
the  primitive  functions  together  to  form  an  entire 
model  of  the  system  to  be  developed. 

2.  Step  2  -  Identify  the  afferent,  efferent,  and 
central  transform  branches  of  the  system. 

Determine  the  afferent  and  efferent  branches  of  the 
system  first.  The  remainder  of  the  system  is 
considered  as  the  central  transform. 

The  afferent  branch  is  determined  by  identifying 
‘  the  afferent  data  elements.  Afferent  data  elements 
are  those  data  flows  that  are  the  last 
representations  of  input  in  a  EFD.  They  are  the 
data  elements  that  are  last  in  the  input  stream  (s) 
of  the  DFD.  An  afferent  data  element  is  the  output 
of  the  last  transformation  on  input. 

The  efferent  branch  is  determined  by  identifying 
the  data  flow  that  represents  the  first  phase  of 
output.  The  efferent  data  elements  are  those 
elements  at  the  beginning  of  each  output  stream  of 
the  DFD. 

Draw  arcs  between  the  afferent  data  elements  and 
the  transforms  into  which  they  flow.  Also,  draw  an 
arc  between  each  efferent  data  element  and  the 
transform  that  outputs  it. 

An  example  of  a  DFD  that  has  been  divided  into 
afferent,  efferent,  and  central  transform  branches 
is  provided  by  Figure  3.2. 4-2. 

Step  3  -  Do  first  level  factoring.  This  involves 
identifying  the  subproblems  of  the  system  and 
forming  the  first  two  levels  of  the  structure 
chart.  Some  subproblems  are  directly  related  to 
the  afferent  and  efferent  data  elements  and  the 
afferent  and  efferent  streams  within  the  DFD. 

Other  subproblems  come  from  the  central  transform 
branch  of  the  system.  A  possible  first-cut 
factoring  for  the  diagram  in  Figure  3. 2. 4-2  is 
illustrated  by  Figure  3. 2. 4-3. 

Step  4  -  Factor  the  afferent,  efferent,  and  central 
transform  branches  established  in  Step  3. 
Progressively  deccmpose  each  subproblem  until  you 
have  decomposed  it  to  its  most  primitive  level. 
Figures  3. 2. 4-4,  3. 2. 4-5,  and  3. 2. 4-6  illustrate 
factoring  of  the  afferent,  efferent,  and  central 
transform  branches  of  the  system  subproblems 
illustrated  in  Figure  3. 2. 4-3. 
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Figure  3. 2. 4-4  Factoring  of  an  Afferent  Branch. 


Figure  3. 2. 4-5  Factoring  of  an  Efferent  Branch. 


Figure  3.2.4-11  Jackson  design  approach. 


Data  Structures 


Program  Structure 


Figure  3.2.4-12  Data  structure  correspondences  and  program  structure. 
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Figure  3.2.4-13  Program  structure  with  operations  allocated 
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Program  structure  (operations  allocated) 


Step  5  -  Identify  and  explain  all  departures  from  normal 
transform  analysis  that  may  be  required  because  of 
the  nature  of  the  problem. 

b.  Transaction  Analysis  steps 

Step  1  -  Identify  the  sources  of  transactions  in  the 

DFD.  Look  for  routing  and/or  distributed  functions 
in  the  DFD.  Figure  3. 2. 4-8  illustrates  a  DFD 
transaction  center. 

Step  2  -  Specify  the  appropriate  transaction-centered 

organization.  Figure  3. 2. 4-9  is  an  example  of  how 
a  transaction  center  might  be  organized. 

Step  3  -  Identify  the  transactions  and  their  defining 

actions.  The  actions  associated  with  transactions 
originating  from  the  environment  may  be  adequately 
defined  in  the  Ada  Bequirements  Document.  However, 
the  designer  must  define  the  actions  associated 
with  internally  generated  transactions  not 
addressed  in  the  Ada  Beguirements  Document. 

Step  4  -  Note  potential  situations  in  which  modules  can 
be  combined. 

Step  5  -  For  each  transaction,  or  cohesive  collection  of 
transactions,  specify  a  transaction  module  to 
completely  process  it.  Avoid  excessive  groupings 
of  transactions  into  one  transaction  processor. 

Step  6  -  For  each  action  in  a  transaction,  specify  an 
action  module  subordinate  to  the  appropriate 
transaction  module  (s). 

Step  7  -  For  each  detailed  step  in  an  action  module, 

specify  an  appropriate  detail  nodule  subordinate  to 
any  action  module  that  needs  it. 

Both  transform  analysis  and  transaction  analysis  are  described  in 
much  greater  detail  in  the  Structured  Design  book  authored  by 
Yourdon  and  Constantine.  Transfers  analysis  is  described  in 
chapter  10,  and  transaction  analysis  is  described  in  chapter  11. 
Examples  of  both  strategies  are  provided  in  these  chapters. 

According  to  Yourdon  and  Constantine,  transform  analysis  is 
preferred  over  transaction  analysis.  However,  they  do  recognize 
that  some  systems  are  very  such  transaction-driven  and  suggest 
judicious  application  of  transaction  analysis.  Perhaps  a 
combination  strategy  which  utilizes  transform  analysis  as  the 
primary  driving  force  and  utilizes  transaction  analysis  as 
appropriate  in  the  subproblems  cf  the  system  is  the  optimum 
approach. 


Guidelines  for  denoting  concurrency  on  the  system  structure  chart 
are  as  follows: 

a.  Tasks  are  represented  by  parallelograms  (see  Figure 
3.2.4-10). 

b.  &  dashed  line  is  used  fcr  a  directed  arc  from  the 
activating  module  to  the  task.  Whether  the  activation 
is  intended  to  occur  automatically  or  by  an  allocator 
should  be  noted  in  the  documentation  of  the  activating 
module. 

c.  A  dashed  line  is  used  fcr  a  directed  arc  from  a 
dependent  task  to  the  owning  nodule.  A  notation  should 
appear  in  the  documentation  of  the  activating  module  and 
in  the  owning  module  (they  may  often  be  the  same  module) 
as  to  the  dependency  cf  each  task. 

d.  A  solid  line  is  used  to  connect  modules  and  tasks  to 
show  synchronization  and  data  transfer. 

Figures  3.2.4-11,  3.2.4-12  and  3.2.4-13  illustrate  a  hierarchical 
program  structured  developed  by  utilizing  the  Jackson  approach. 
Figure  3.2.4-14  shows  the  structure  chart  developed  from  a 
functional  decomposition.  Note  that  utilization  of  the  Parnas 
approach  or  some  new  approach  that  may  soon  surface  may  give  rise 
to  a  different  hierarchical  structure  chart. 


3.2.5  “Goodness"  Criteria 
3.2.5. 1  Description 

Intuitively,  given  two  system  designs  that  are  both  correct,  cne 
design  say  be  better  than  the  other  because  it  is  more  easily 
■aintained,  it  uses  fewer  resources,  etc.  In  stating  that  one 
design  is  better  than  another,  qualitative  evidence  may  be 
presented,  A  set  of  metrics  will  be  used  as  “goodness"  criteria. 
The  goodness  criteria  is  important  not  only  for  evaluating 
designs;  it  can  also  be  used  to  drive  good  design.  Clearly,  if  a 
design  analyst  knows  the  criteria  against  which  his/her  product 
will  be  judged,  he/she  can  make  better  design  decisions 
initially. 

Undoubtedly,  there  is  not  a  universal  set  of  design  criteria  that 
is  equally  applicable  to  all  system  designs.  In  fact,  certain 
good  design  practices  are  often  mutually  exclusive  and  have  to  be 
traded  off.  While  management  should  make  the  ultimate  decisions 
regarding  the  goodness  criteria,  recent  evidence  evaluating  the 
software  life-cycle  suggests  that  maintainability  should  be  the 
last  design  objective  to  be  sacrificed  (except  when  real-time 
response  constraints  must  be  net) .  This  philosophy  is  certainly 
consistent  for  the  DoD  in  their  embedded  systems  work. 
Consequently,  a  minimum  set  of  metrics  will  be  proposed  to 
support  the  criteria  for  improved  maintainability,  but  the  set 
should  in  no  way  be  considered  complete  in  light  of  differing 
management  objectives. 

Two  structured  design  metrics  will  be  used  to  evaluate  and  drive 
each  design  step  in  an  iterative  cycle.  The  measures  are 
cohesion  and  coupling  (Yourdon  and  Constantine) .  The  basic 
philosophy  behind  these  measures  is  that  a  higher  degree  of 
maintainability  is  achieved  as  the  modules  that  comprise  the 
software  design  become  more  independent.  Independence  is 
measured  by  how  well  the  elements  comprising  a  module  are  related 
(cohesion)  and  to  what  degree  the  various  modules  comprising  the 
system  are  interrelated  (coupling).  Typically,  better 
independence  is  achieved  when  cohesion  is  maximized,  and  coupling 
is  minimized.  Descriptions  of  coupling  and  cohesion  are  provided 
below. 

a.  Cohesion  -  As  stated  above,  cohesion  is  a  qualitative 
measurement  of  the  relationship  among  the  elements 
within  a  single  module.  Using  flyers  terminology 
cohesion  is  stated  in  terms  of  module  strength,  with  the 
strongest  (most  cohesive)  module  being  cf  informational 
or  functional  strength,  and  weakest  module  (least 
cohesive)  being  of  coincidental  strength.  The  seven 
categories  of  cohesion,  from  highest  to  lowest  strength, 
are: 

7.  Informational  strength 
6.  Functional  strength 
5.  Comnunicational  strength 
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4.  Procedural  strength 
3.  Classical  strength 
2.  Logical  strength 
1.  Coincidental  strength 

The  scale  above  is  based  on  a  study  by  Constantine  in 
which  he  evaluated  aodules  in  specified  classes  with 
respect  to  prograa  saintainability ,  extensibility, 
independence,  error-prcneness,  and  aodule  reuseability. 
Consequently,  the  scale  indicates  a  relationship  among 
aodules,  inferring  for  exaaple  that  procedural  strength 
aodules  are  "better"  than  classical  strength  aodules. 
Note,  however,  that  this  scale  is  a  guideline  and 
peculiar  aspects  of  a  problem  nay  dictate  that  a  lower 
strength  aodule  is  appropriate  (the  designer  should, 
however,  be  able  to  defend  a  decision  to  use  soaething 
other  than  an  inf oraational  or  functional  strength 
aodule) . 

Presented  below  is  a  definition  and  example  of  module 
strength  for  each  element  on  the  scale.  A  more 
elaborate  discussion  is  presented  in  flyers. 

1.  Coincidental-strength  aodule:  is  a  module  whose 
function  cannot  be  described  (other  than  by  the 
logic  that  comprises  the  aodule)  cr  one  that 
performs  multiple,  completely  unrelated  functions. 

2.  Logical-strength  aodule:  is  one  that  performs  a 
set  of  related  functions,  one  of  which  is 
explicitly  selected  by  the  calling  module  (note:  a 
logical  strength  module  has  a  single  interface  for 
multiple  functions) . 

3.  Classical-strength  aodule:  is  one  that  performs 
multiple  sequential  functions  where  there  is  a 
weak,  but  nonzero,  relationship  among  all  of  the 
functions.  Common  examples  are  "initialization" 
and  "termination"  procedures. 

4.  procedural -strength  aodule:  is  a  aodule  that 
performs  multiple  sequential  functions,  where  the 
sequential  relationship  among  all  the  functions  is 
implied  by  the  problem  or  application  statement. 

An  exaaple  of  a  procedural-strength  module  would  be 
one  that,  in  response  to  an  invalid  transaction, 
would  skip  to  the  next  transaction,  checkpoint  the 
master  file,  and  display  an  error  message  on  the 
operator  console. 

5.  Coamunicational-strength  module:  is  one  that 
performs  multiple  sequential  functions,  where  the 
sequential  relationship  among  all  the  functions  is 
implied  by  the  problem  or  application  statement  and 
where  there  is  a  data  relationship  among  all  of  the 
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functions.  For  exaaple  a  nodule  that,  in  response 
to  an  invalid  transaction,  "prints  the  transaction 
and  copies  it  to  the  audit  file"  exhibits 
connunicational  strength. 

6.  Functional-strength  nodule:  is  a  nodule  that 
perforns  a  single,  specific  function. 

7.  Informational-strength  nodule:  is  a  grouping  or 
package  of  functional  strength  modules  for  the 
purpose  of  information  hiding. 

b.  Coupling  -  Coupling  is  a  measure  of  strength  of 

interconnection  (i.e.,  communication  bandwidth)  between 
modules.  Coupling  is  a  measure  that  is  both  qualitative 
and  quantitative.  The  nunber  of  parameters  passed  to  a 
nodule  is  a  quantitative  measure  of  coupling.  The  type 
of  interfaces  between  nodules  is  a  qualitative  neasure 
of  coupling.  Also,  when  coupling  is  minimized,  implying 
the  weakest  strength  interconnection  nodel,  the  greatest 
nodule  independence  is  achieved.  The  seven  categories 
of  nodule  coupling  fron  lowest  (best)  to  highest  (worst) 
strength  are: 

1.  No  direct  coupling 

2.  Data  coupling 

3.  Stanp  coupling 

4.  Control  coupling 

5.  External  coupling 

6.  Conmon  coupling 

7.  Content  coupling 

Again,  the  original  classifications  and  ordering  of 
coupling  were  based  on  a  study  by  Constantine  in  which 
he  evaluated  nodules  in  specified  classes  with  respect 
to  program  maintainability ,  extensibility,  independence, 
error-proneness,  and  nodule  reuseability .  Nyer's 
coupling  scale  above  is  very  similar  to  Constantine's 
original  classifications  and  ordering  of  coupling.  As 
was  the  case  with  the  cohesion  (module  strength)  scale, 
the  coupling  scale  implies  an  order  of  desireability 
among  the  types  of  coupling  and  the  design  engineer 
should  be  prepared  to  justify  his/her  decision  should 
something  less  than  data  coupled  modules  be  designed. 

Presented  below  is  a  definition  and  exaaple  of  nodule 
coupling  for  each  element  on  the  scale.  A  more 
elaborate  discussion  is  presented  in  Myers. 

1.  Content-coupling:  two  modules  are  content  coupled 
if  one  directly  references  the  insides  of  the  ether 
or  if  the  normal  linkage  conventions  between  the 
modules  are  bypassed.  For  exaaple,  twe  assembly- 
language  modules  A  and  B  are  content  coupled  if  A 


67 


references  a  word  at  sose  numerical  offset  from  the 
beginning  of  B. 

2.  Common-coupling:  occurs  between  a  group  of  modules 
that  reference  a  global  data  structure.  The 
FORTRAN  COMMON  area  exemplifies  cotton  coupling. 

3.  External-coupling:  a  group  of  modules  are  external 
coupled  if  they  are  not  content  or  common  coupled 
and  if  they  reference  a  homogeneous  global  data 
item.  External  coupling  occurs  in  FORTRAN  with  the 
use  of  labeled  common  areas. 

4.  Control-coupling:  two  modules  are  control  coupled 
if  they  are  not  content,  common,  or  external 
coupled  and  if  one  module  explicitly  controls  the 
logic  of  the  other,  that  is,  one  module  passes  an 
explicit  element  of  control  to  the  other  module. 
Examples  of  "elements  of  control"  are  function 
codes  transmitted  to  logical-strength  modules, 
control-switch  arguments,  and  module-name 
arguments. 

5.  Stamp-coupling:  two  modules  are  stamp  coupled  if 
they  are  not  content,  common,  external,  or  control 
coupled  and  if  they  reference  the  same  nonglobal 
data  structure.  Stamp  coupling  is  similar  to 
common  coupling  except  the  shared  data  structure  is 
not  global. 

6.  Oata-coupling:  two  modules  are  data  coupled  if  (1) 
they  are  not  content,  common,  external,  control,  or 
stamp  coupled,  (2)  if  the  modules  directly 
communicate  with  one  another  (one  directly  calls 
the  other) ,  and  (3)  if  all  interface  data  between 
the  modules  are  homogeneous  data  items. 

7.  No-direct-coupling:  as  the  name  suggests  this  is  a 
module  that  does  not  have  any  intermodule 
relationships. 

3. 2. 5. 2  Guidelines 

Once  a  structured  design  decomposition  has  been  completed  three 
steps  should  be  taken  to  review  the  design  before  proceeding. 
These  steps  involve  the  application  of  the  coupling  and  cohesion 
metrics  to  improve  the  design  and  to  verify  its  guality 
("goodness").  The  steps  are:  post  analysis  of  packaging,  static 
design  review,  and  dynamic  design  review  (Myers)  . 

a.  Post  Analysis  of  Packaging 

With  the  object-oriented  development  available  from  the 

first  part  of  the  design  effort,  one  analyzes  the 

hierarchy  chart  to  identify  those  objects  that  can  be 


collected  into  packages.  This  reconciliation  phase  will 
result  in  the  identification  of  objects  utilizing  a 
special  notation,  patterned  after  Booch,  that  will  be 
folded  back  into  the  original  structure  or  hierarchy 
chart. 

Post  analysis  of  object  oriented  design  implies 
reviewing  the  design  to  ensure  that  nodule  independence 
in  the  program  has  been  aazinized.  The  nost  important 
vehicle  for  doing  this  is  the  inf ornational  strength 
nodule  or  Ada  package.  The  design  should  be  reviewed 
looking  for  implicit  or  explicit  assumptions  and 
dependencies  among  modules,  complex  design  decisions 
that  can  be  isolated,  cr  operations  on  common  data  that 
could  be  abstracted.  These  and  other  guidelines  can  be 
guided  by  the  pre-packaging  analysis  described  above. 
Hhen  these  dependencies  or  complexities  exist,  or  when 
suggested  by  the  pre-packaging  analysis,  informational 
strength  modules  (Ada  packages)  should  be  constructed  to 
eliminate  dependencies  and  enhance  the  design.  Parnas 
suggests  the  following  guidelines  in  identifying  data  or 
functions  to  be  collected: 

1.  Each  module  should  hide  some  design  decision  from 
the  rest  of  the  system. 

2.  A  data  structure,  its  internal  linkings,  accessing 
procedures,  and  modifying  procedures  should 
comprise  a  single  module. 

3.  The  format  of  control  blocks  (data  structures)  must 
be  bidden. 

4.  Character  codes,  alphabetic  orderings,  and  similar 
data  should  be  hidden. 

5.  The  sequence  in  which  certain  items  will  be 
processed  should  (as  far  as  practical)  be  hidden 
within  a  module. 

6.  Preferred  reason  fcr  packaging  is  to  hide  some 
aspect  of  the  implementation  within  the  package- 
body;  this  may  be  data  structures,  data  types, 
common  subprograms,  or  common  packages. 

7.  A  good  reason  fcr  packaging  is  in  support  of 
abstract  data  types  in  which  the  type  must  be  made 
visible  in  the  package-declaration  but  its  physical 
structure  may  be  hidden  in  the  private  porticn. 

8.  Another  less  compelling  but  valid  reason  for 
packaging  is  to  gather  together  objects  which  are 
referenced  by  the  same  set  of  other  modules,  to 
reduce  the  number  of  library  units. 
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Data  or  functions  which  are  collected  are  graphically 
depicted  as  shown  in  Figure  3. 2. 5-1.  Windows  represent  entry 
points  into  the  objects  reali2ed  by  the  graphical  notation. 
The  graphical  object  is  given  a  naae  and  the  entry  points  are 
also  appropriately  named.  This  description  of  the  objects 
can  then  be  realized  in  the  hierarchy  chart  as  shown  in 
Figure  3.2. 5-2.  Note,  that  the  interconnectivity  is  still 
intact  from  the  original  chart  or  if  data  flew  is  represented 
on  the  arcs,  this  flow  is  still  intact. 

b.  Static  Design  Seview 

Static  design  review  is  simply  an  inspection  of  the 
completed  design  with  respect  to  a  set  of  criteria  and 
guestions.  The  analysis  is  best  carried  out  by  an 
independent  reviewer  with  the  intent  of  uncovering 
design  weaknesses,  not  tc  make  immediate  improvements. 
The  correction  of  uncovered  weaknesses  is  best  delayed 
until  after  the  review  is  complete  so  that  hasty  or  ill- 
conceived  changes  are  not  incorporated  into  the  design. 

Myers  presents  the  following  set  of  guestions  as  being 
reasonable  for  a  static  review: 

1.  Does  each  module  have  functional  or  informational 
strength?  If  any  dc  not,  then  why  not? 

2.  Is  r.\  ch  pair  of  modules  either  data  coupled  or  not 
directly  coupled?  If  any  are  not,  why  not? 

3.  Is  the  decomposition  complete?  That  is,  can  the 
logic  of  each  module  be  easily  visualized? 

4.  when  a  module  or  entry  point  has  a  fan-in  greater 
than  2  (i.e.,  multiple  immediate-superordinate 
modules) ,  are  the  interface  definitions  to  the 
module  consistent?  That  is,  does  each  interface  to 
the  module  have  the  same  number  of  input  arguments 
and  the  same  number  of  output  arguments?  Does  each 
corresponding  argument  in  each  interface  have  the 
same  attributes? 

5.  Is  there  any  unnecessary  redundancy  in  any 
interface? 

6.  Is  the  interface  data  to  each  module  consistent 
with  the  definition  of  the  module's  function? 

7.  Are  there  multiple  modules  in  the  system  that 
appear  to  have  the  same  funi  ion? 

8.  Is  each  module  described  by  its  function  rather 
than  by  its  context  or  logic?  Has  each  function 
been  stated  accurately? 


9.  Are  there  any  pre-existing  nodules  that  could  have 
been  used  in  this  system? 

10.  Are  there  any  restrictive  nodules  (i.e.,  nodules 
that  are  unnecessarily  overspecialized)  ? 

11.  Are  all  nodules  predictable  (i.e.,  do  the  sane 
inputs  produce  the  sane  outputs  for  each 
invocation) ? 

12.  Is  the  design  realizable  by  the  Ada  progranning 
language? 

13.  Is  the  hierarchical  structure  too  extrene  (e.g., 
overly  "short  and  fat"  or  "tall  and  lean") ?  Note, 
such  extrene  structures  do  not  necessarily  inply 
problens,  but  they  should  be  explored  because  they 
could  indicate  that  the  deconposition  used  was 
incorrect. 

14.  Is  the  design  correct  (i.e.,  are  all  items 
specified  in  the  reguirenents  document  readily 
identified  in  the  system  design)? 

15.  Have  rules  of  parsinony  been  followed?  That  is, 
does  the  systen  do  only  that  stated  in  the 
requirements  docuaent? 

16.  Is  the  design  obscure?  Does  it  contain  anything 
that  night  easily  be  nisunderstood? 

17.  Have  any  unstated  assumptions  been  made? 

c.  Dynamic  Design  Heview 

This  is  a  nental  "walk-through"  of  the  program.  It 
begins  by  developing  a  set  of  tests  and  then  tracing  the 
state  of  the  system  as  it  would  change  in  response  to 
the  steps  of  the  test.  Since  some  logic  might  not  exist 
at  the  time  of  the  dynamic  review,  the  functionality  of 
"stub"  nodules  can  be  assumed  to  be  correct.  The 
purpose  of  the  review  is  to  find  design  flaws  such  as: 
missing  or  incomplete  functions;  erroneous  interfaces; 
incorrect  results;  etc. 

See  Figures  3. 2. 5-3  and  3.2. 5-4  for  examples  of  the  application 
of  some  aspects  of  the  above  discussion  pertaining  to  the 
reconciliation.  Clearly,  the  application  of  coupling  and 
cohesion  is  subjective  at  best  but  by  utilizing  the  above 
considerations  one  should  determine  a  coupling  and  cohesion  level 
for  each  module  and  module  relationship. 


3.2.6  Requirements-; to- Design  Traceabj,ljty 

3.2.6. 1  Description 

Traceability  of  requirements  to  design  is  a  link  in  the  chain  of 
traceability  from  user  specifications  to  actual  implementation 
program  units.  The  purpose  of  requirements-tc-design 
traceability  during  development  is  two-fold.  First,  the  tracing 
of  requirements  to  design  facilitates  the  evaluation  of  changes 
to  the  requirements  during  development  of  the  system.  Secondly, 
it  provides  some  form  of  verification  that  the  design  does 
satisfy  the  requirements. 

The  traceability  step  occurs  at  tvo  points  in  the  design  process. 
Pirst,  traceability  is  applied  immediately  after  evaluating  the 
Goodness  of  design  (3.2.5).  If  it  is  determined  at  this  point 
that  the  design  does  satisfy  the  requirements,  the  designer 
should  proceed  with  step  3.2.1  (Data  Structures). 

The  second  time  traceability  is  applied  is  during  detail  design 
at  step  3.3.2  (Final  Design  Review).  Of  course,  if  any 
requirements  cannot  be  traced  to  design  at  this  point,  the  design 
must  be  corrected  before  completing  the  final  design  review  and 
proceeding  to  the  implementation  phase. 

3. 2. 6. 2  Guidelines 

Guidelines  a  through  f  are  to  be  performed  as  tasks  in  the  order 
specified.  Whereas  guidelines  g  and  h  are  only  suggestions. 

a.  Develop  a  matrix  to  map  Ada  Requirements  Document 
components  into  Ada  Design  Document  components. 

b.  Develop  a  set  of  Ada  Requirements  Document  components  tc 
be  mapped  into  Ada  Design  Document  components.  A 
possible  set  of  Ada  Requirements  Document  components  is 
provided  below: 

DIAGRAM  BOX  NUMEEH 
NCN-FUNCTICNAL  REQUIREMENT 
CONCURRENCY  REQUIREMENT 

It  will  be  necessary  to  use  some  kind  of  identification 
mechanism  to  abbreviate  actual  non-functional  and 
concurrency  requirements  on  the  traceability  matrix. 

c.  Develop  a  set  of  Ada  Design  Document  components  to  be 
used  in  the  mapping  process  from  requirements  to  design. 
A  possible  set  of  Ada  Design  Document  components  is 
provided  below: 

SUBPROGRAM  NAME 
PACKAGE  NAME 

PACKAGE  NAME. SUBPROGRAM  NAME 
PACKAGE  NAME. TASK  NAME 
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d.  flap  each  Ada  Reguirenents  Docunent  coapcnent  to  an  Ada 
Design  Docuaent  coapcnent. 

e.  Do  a  reverse  aapping  frca  design  to  reguirenents  after 
the  initial  napping  of  reguirenents  to  design. 

f.  Ose  the  results  of  the  forward  and  backward  aapping  of 
reguirenents  and  design  to  verify  that  the  design  does 
satisfy  the  reguirenents. 

g.  Try  to  nap  each  Ada  Reguirenents  Docuaent  coaponent  into 
as  snail  an  Ada  Design  Docuaent  coaponent  as  possible. 

h.  Arrange  the  Ada  Beguirenents  Docuaent  ccnponents  in 
categorical  order  on  the  traceability  aatrix.  For 
example,  aap  all  the  low-level  functional  blocks 
associated  with  each  aajor  function  first  (in  aajor 
function  order)  and  then  aap  the  non-functional  and 
concurrency  reguirenents  in  that  order. 

Table  3. 2. 6-1  is  an  exaaple  of  a  traceability  aatrix  that 
illustrates  the  aapping  of  reguirenents  to  design. 
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3.2.7  Uo^ulg_In^erc2Qnes£iziiI 
3. 2. 7.1  Description 

Module  interconnectivity  is  described  via  an  N2  chart.  The  H2 
chart  is  constructed  by  utilizing  a  matrix  as  described  in  "The 
S2  Chart",  by  B.  J.  Lano.  It  is  a  square  matrix,  with  all 
functions  on  the  diagonal,  all  outputs  of  a  function  are 
horizontal  (left  or  right) ,  all  inputs  are  vertical  (up  or  down)  , 
thus  all  non-diagonal  (non-f unction)  positions  define  one-way 
interfaces  between  the  respective  functions. 

N2  charts  and  interconnectivity  charts  are  used  to  document  the 
interfaces  of  the  final  architectural  design.  The  structure 
chart  is  the  mechanism  that  is  used  during  multiple  iterations  of 
architectural  design  to  evaluate  and  change  the  structure  of  the 
system. 


3. 2. 7.2  Guidelines 

a.  Using  the  final  structure  chart  of  architectural  design 
and  beginning  with  the  number  1,  sequentially  number  all 
modules  on  the  chart  until  all  modules  have  been 
assigned  a  unique  number. 

b.  Construct  an  S-squared  chart,  i.e.,  represent  the 
modules  along  the  diagonal  in  numerical  order. 

c.  On  the  N-squared  chart  indicate  which  interfaces  exist. 

d.  Adopt  a  numbering  scheme  for  interfaces;  possibilities 
include  assigning  unique  sequential  numbers  left-to- 
right,  top-to-bottom ,  cr  using  matrix  position 
outputting  function  nunfcer-dash-inputting  function 
number. 


J 
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Figure  3. 2. 7-1 


Example  Sequence  of  Processes 
with  Direct  Data  Links. 
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Figure  3. 2. 7-2  Example  Sequence  of  Processes  with 
Main  Module  Controlling  all  Data. 
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3.2.8  *£aliaiaaii-fissisii_.Bsviev 


The  preliminary  design  review  is  an  internediate  point  in  the 
design  process  where  the  designer  stops  and  reviews  the  overall 
functional  design  developed  to  date.  Any  discrepancies  noted  at 
this  point  should  be  corrected  through  iterations  of  the 
appropriate  design  steps  previously  stated  (3.2.1  -  3.2.7). 
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3.2.9  Ada_Onit_ Specifications 
3.2.9. 1  Description 
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System  architectural  design  as  so  far  described,  expressed  and 
documented  as  structure  charts,  interconnectivity  charts,  H2 
charts,  and  package  charts,  can  now  be  expressed  using  Ada 
constructs  and  program  organization.  Since  AIM  provides  system 
design  specification  and  development  in  terms  of  units  and 
constructs  compatible  with  Ada  language  design  philosophy,  system 
expression  in  Ada  should  be  iscmcrphic  to  architectural  design. 
The  structure  created  during  architectural  design  can  be 
implemented  with  the  Ada  compilation  units.  The  uppermost 
control  module  must  be  a  subprogram  as  the  Ada  Reference  Manual 
in  Chapter  10  states  only  "a  subprogram  can  be  a  main  program". 
The  remainder  of  the  modules  determined  during  architectural 
design  may  be  represented  by  declarations  in  the  packages 
selected  during  architectural  design,  or  by  subprogram 
declarations,  or  by  body  stubs  in  the  parent  modules  if  the 
implementations  selected  are  subunits. 

3. 2. 9. 2  Guidelines 

The  guidelines  for  formulating  Ada  specifications  from 
architectural  design  are  listed  below: 

a.  The  main  program  or  uppermost  control  module  must  be 
formulated  as  an  Ada  subprogram. 

b.  When  formulating  package  declarations  only  include 
objects  which  must  be  visible  to  external  modules. 

c.  When  type  declarations  appear  in  package  declarations, 
use  the  private  portion  of  the  package  to  protect  the 
structure  of  the  type  from  direct  manipulation  by 
external  modules  when  possible. 

d.  Hide  as  many  internal  objects  of  packages  within  their 
respective  bodies  as  possible  so  that  they  are  hidden 
from  external  modules  and  do  not  influence  the 
compilation  of  the  package  declaration. 

e.  A  subprogram  or  package  which  is  only  referenced  by  cne 
module  may  be  nested  within  that  one  module  and 
implemented  as  a  subunit,  or  it  may  be  declared  as  a 
library  unit;  as  a  subunit  it  would  inherit  the  context 
of  its  parent,  and  as  a  library  unit  it  would  be 
accessible  from  other  units  through  their  context 
specifications. 

f.  Activation  of  a  task,  which  can  be  controlled  by  point 
of  declaration  or  by  point  of  creation  by  an  allocat 
should  be  carefully  selected. 
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g.  As  detailed  is  Section  9.4  of  the  Ida  Beference  Bannal  a 
block  or  body  with  dependent  tasks  is  net  left  until  all 
dependent  tasks  have  terminated;  therefore,  care  oust  be 
exercised  in  assigning  these  dependencies  which  are 
controlled  by  the  placesent  of  task  object  declarations 
and  access  type  declarations. 

The  following  shall  be  the  general  foraat  of  the  Ada  program  nnit 
specifications: 

a.  Context  declarations,  as  necessary 

b.  Unit  specif icaticns,  including  paraaeter  lists 

c.  Prologue  (as  consents):  Author,  date,  revision  level; 
functional  description  and  reguiresents  traceability 

d.  Variable  and  aggregate  type,  range,  and  enuneration 
declarations 

e.  Subunit  declarations,  including  paraaeter  lists 

f.  Entry  declarations  for  tasks 

In  addition,  the  following  body  declarations  can  be  nade  as 
reguired: 

a.  Stubs  for  hidden  procedures  and  functions 

b.  Definitions  for  hidden  data. 

3. 2. 9. 3  SsafiElS 

Example: 

with  BESSAGE 


package  BAILBOX  is 

—  J.  K.  Writer 

—  10  DEC  1981  BEV  A 

—  Bef.  A231,  A232 


type  LINE-ID  is  private; 


procedure  GET-LINE  (BI: 

ID: 

procedure  BECEIVE  (IS: 

BSG: 

procedure  SEED  (ID:  in 

BSG:  in 


in  BISSAGE. BOOTS; 
out  LINE-ID) ; 
in  LINE-ID; 
out  BESSAGE. BUEEEB) ; 
LINE-ID; 

BESSAGE.BOEFEB) ; 


private 

type  LIHE-IE  is  new  INTEGEB ; 
end  BAILBOX; 
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3.2.10  flfl£a*ais252fi »aia-£a£i iiiaiiifla 

3.2.10.1  Description 


3.2.10.1.1  Sa^j.onale.  AIR  is  intended  to  be  applied  to  the 
design  of  coeplez  embedded  systeas,  typically  consisting  of 
fixed,  pre-defined  hardware  coaponents  and  functionally 
integrated  by  programs  operating  cn  one  or  nore  digital 
processors.  At  soae  point  in  the  process  of  systea  definition, 
systea  functions  will  be  distributed  among  hardware  and  software 
coaponents.  There  is  soae  degree  of  variability  with  respect  to 
when  in  the  systea  definition  process  such  allocation  takes 
place.  One  reason  for  this  is  that  perforaance  evaluation 
standards  are  still  evolving:  a  rigorous  performance  evaluation 
aethodology  will  enable  designers  to  rationally  distribute 
hardware  and  software  functions  based  on  perforaance,  cost, 
resource,  and  procurement  constraints.  Project  aanageaent 
generally  desires  hardware  allocation  to  be  made  as  early  as 
possible  so  that  procureaents  can  be  initiated  in  a  tiaely 
Banner.  ' 


3.2. 10. 1.2  Prelim  ip  grjes.tg,  H^rdware^Softw^^  Pa£tj$j,gBipg. 
This  section  addresses  the  design  status  that  shculd  exist  at  the 
tiae  of  allocation  of  system  functions  to  hardware  and  software. 
Hardware/software  partitioning  (HSP)  is  the  last  task  of 
architectural  design  prior  to  detail  design.  This  concept  of  BSP 
is  coapatible  with  general  AIR  design  philosophy.  The  object- 
oriented  architectural  design  allows  early  identification  of 
perforaance-critical  attributes.  The  AIR  methodology  provides 
for  software  prototyping  of  critical  performance  functions  prior 
to  any  detail  design. 

The  following  is  a  list  of  inputs,  or  design  states,  to  HSP 
activity: 

a.  Rajor  functional  partitioning  of  the  systea  -  structure 
chart  of  major  functional  modules  and  H*  charts  showing 
module  interfaces. 

b.  High-level  concurrency  model  showing  task  structure. 

c.  Performance  requirements  including: 

1.  Volume  of  data  transaission  (internally  and  to 
external  hardware) 

2.  Processing  constraints  in  terms  of  data 
transformations  within  systea-defined  event 
intervals 

3.  Identification  of  time-critical  functions 

4.  I/O  requirements  including  resource  requirements, 
access  frequency,  media  requirements 
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5.  Identification  of  likely  nodifiable  functions 
(including  adaptability  requirements  given  by 
systea  spec) 

6.  Identification  of  hardware  control  functions 
(including  display  and  operator  coanunication)  for 
possible  assignment  to  interface  hardware 

7.  Software  allocation  -  those  functions  definitely 
assigned  to  software,  including  major  utility  and 
library  functions 

8.  Determination  of  redundancy  and  diagnostic 
requirements. 

d.  Data  structures. 

1.  Model  of  logical  data  structures  (developed  during 
requirements  and  step  2  of  architectural  design) . 

2.  Jackson  data  structures. 

3.2.10.2  Guidelines 

3.2.10.2.1  Facb<?£§«  Factors  that  influence  the  allocation 

of  system  functions  to  hardware  and  software  are  considerations 
of  flexibility,  efficiency,  ccst,  resources,  level  of  effort, 
etc.  Bore  specifically,  design  questions  pertain  to  the 
following  areas: 

a.  Performance  and  resourgg  constraints.  As  a  result  of 
requirements  analysis,  the  implications  for  performance 
evaluation  cf  processing  requirements  will  be  specified. 
Processing  requirements  include  internal  storage 
capacity,  data  transmission  capacity  (in  terms  of  rate 
and  volume) ,  file  capacity,  general  features  of  file 
organization  and  associated  access  methods,  display 
requirements,  operator  interface  response  time,  and 
concurrency  reguired  by  system  definition,  system 
design  reflects  solutions  to  the  problems  imposed  by 
these  constraints;  distribution  of  hardware  and  software 
functions  is  an  expression  of  these  solutions. 

b.  Maintainability.  The  analysis  of  a  complex  embedded 
system  with  an  extended  life  cycle  must  consider 
questions  such  as  the  following:  What  system  functions 
are  most  specialized,  less  general?  What  design 
features  will  be  most  sensitive  to  requirements 
specification  changes?  Which  functions  are 
generalizable  from  current  design  to  a  broader  set  of 
applications  in  the  same  class?  (Bore  specifically, 
for  this  contract:  Tc  what  extent  have  general 
characteristics  of  C3  systems  been  taken  into  account?) 
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The  implication  of  such  questions  for*  hardware/software 
partitioning  is  that  the  moce  generalized  a  system 
function  is,  or  the  more  likely  to  require  modification, 
the  more  likely  it  is  to  be  assigned  to  software,  other 
things  being  equal. 

c.  The  application  environment  of  the 

AH/TYC-39  message  switch  consists  of  various  types  of 
external  hardware  to  which  the  system  must  interface. 

The  system  must  be  adaptable  to  changes  in  system 
configuration.  The  definition  of  system  status  includes 
both  the  maintenance  of  information  necessary  for 
recovery/restart  and  for  the  definition  of  system 
configuration.  HSP  decisions  must  take  account  of  the 
associated  factors  of  reliability,  security,  and 
reconfigurability. 

3.2.10.2.2  •  The 

purpose  of  this  section  is  to  informally  classify  the  broad  types 
of  hardware  functions  in  a  total  system. 

a.  by  syfffrgm ,spegs.  This  is  external 
hardware  to  which  the  embedded  computer  system  must 
interface.  Characteristics  of  the  external  hardware  are 
reflected  in  the  processing  system  specs.  Design 
options  here  involve  the  specification  of  mechanisms  at 
intermediate  interface  levels,  between  the  fixed 
hardware  and  the  processing  system. 

b.  System  architecture.  The  architecture  of  the  embedded 
computer  system"  (the  organization  or  configuration  of 
its  hardware  components)  is  a  design  feature  specified 
as  (1)  a  solution  to  performance  constraints  and  (2)  a 
reflection  of  "good"  design  criteria.  Part  of  the 
specification  expresses  the  choice  between  uni-  and 
multi-processor  architecture.  Hultiprccessor 
configuration  can  be  a  sclution  to  timing  constraints 
and  concurrency  requirements,  and  can  physically  embody 
high-level  design  of  tasking  architecture. 

c.  Special  purpose  hardware  functions.  System  functional 
organization  identifies  groups  of  functions  which  can  be 
allocated  to  either  hardware  or  software.  Choice  of 
allocation,  as  indicated  above,  would  ideally  be  made  on 
the  basis  of  a  methodical  performance  analysis.  In  the 
absence  of  a  well-defined  methodology,  hardware/software 
allocation  must  he  based  on  available  information  on 
performance  requirements  and  constraints,  level  of 
effort,  and  system  adaptability  factors  (reconfiguration 
requirements) .  Availability  of  off-the-shelf  components 
for  given  system  functions  will  influence  allocation 
decisions. 


3.2.10.2.3  HSP  .§aj&as&S«  This  section  addresses  the 
specific  tasks  involved  in  the  hardware/software  partitioning 
activity. 

a.  A  aajor  task  is  the  allocation  of  software  functions  to 
control  processing  hardware.  Choice  of  uni-  and  aulti- 
processor  architecture  will  deteraine  features  of  detail 
design,  as  well  as  the  nature  of  supervisory  functions 
of  systea  software. 

b.  Input/output  control  and  processing  functions  aust  be 
assigned  to  device  drivers. 

c.  Memory  access  nodes  satisfying  data  access  perforaance 
requirements  aust  be  determined.  Decisions  regarding 
data  transnission  and  data  base  access  hardware  aust  be 
aade  and  the  corresponding  software  perforaance 
reguireaent  stated. 

d.  Redundancy  and  diagnostics  provisions  aust  be  allocated. 

e.  Systea  representation  shall  include  graphical  or 
schematic  display  of  the  following: 

1.  Physical  arrangeaent  or  configuration  of  internal 
hardware  ccaponents,  including  processing  units, 
prograa  storage  units,  data  base  storage  units, 
data  and  signal  transnission  and  control  units, 
data  and  signal  paths,  I/O  control  units,  display 
units,  and  operator  devices. 

2.  A  system  structure  chart  as  described  in  3.2.4, 
with  an  indication  of  functional  assignaent  to 
hardware,  as  by  drawing  a  double  line  around 
nodules  or  groups  of  nodules. 
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Figure  3.2.10-1  Example  of  Representation  of  Hardware  Functional  Allocation  on 
Structure  Chart. 


3 . 3 


3.3.1  fi§jtal2B§sat_ajifl_fi22aiSBi  3ii2fl-<2i_islail_£s5ia£ 

iB_A^azf£l 

3. 3. 1.1  Description 

Detail  design  is  an  iterative  activity  which  begins  with  a 
representation  of  system  architecture.  It  ends  when  the  designer 
is  satisfied  that  enough  information  has  been  provided  to 
iapleaentation  and  coding  personnel  to  assure  that  systea 
functional  and  perforaance  reguireaents  will  be  net. 

The  AIH  methodology  provides  that  Ada  will  be  used  to  docuaent 
the  development  of  detail  design;  that  is,  Ada  will  be  used  as  a 
Program  (or  Process)  Design  Language  (PDL) .  Inputs  to  the  detail 
design  activity  include  the  following: 

a.  All  graphical  representations  of  systea  design. 

b.  Ada  unit  specifications  (declarations)  and  descriptive 
coaaentary,  and  body  stubs,  froa  3.2.9. 

c.  Systea  reguireaents  froa  the  A-spec  equivalent,  via  the 
traceability  docuaentation  of  3.2.7. 

d.  Hardware  interface  specs  froa  3.2.10. 

3. 3. 1.2  Guidelines 

3. 3. 1.2.1  DeyeJlgpaept  ,Ag,tiyj.fcy.  Detail  design  decisions 
shall  be  recorded  as  elaborations  of  and  additions  to  the 
architectural  design  expressed  as  Ada  prograa  units  (as  described 
in  3.2.9).  Ada  constructs  shall  be  used  to  express  design 
features  through  successive  stages  of  refineaent,  in  terns  of 
aodule  and  systea  interface  specs,  variable  and  aggregate  type, 
range,  or  enuaeration  specification,  selection  and  decision 
logic,  data  definition,  and  algoritha  functional  specification. 

3.3. 1.2.2  Foraat.  The  general  fora  of  an  Ada/PDL  unit  shall 
be  as  follows: 

a.  prograa  unit  specification; 

b.  prologue  (author,  date,  functional  description,  revision 
level) ;  NOTE:  if  the  unit  is  a  body  that  has  a 
corresponding  unit  specification  produced  as  described 
in  3.2.9,  the  revision  level  of  that  unit  spec  shall  be 
prefixed  to  the  revision  level  of  the  body; 

c.  unit  design  in  terms  cf  Ada  constructs. 

Any  feature  or  construct  of  the  Ada  language  nay  be  used. 

Prograa  constructs  shall  be  balanced  but  otherwise  are  not 
required  to  be  compilable.'  Logical  commentary  may  be  used  freely 
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to  describe  progras  unit  function  or  subfunction  within  a  unit. 
"Action"  coaaentary  (preceded  by  " — >")  say  be  used  to  indicate 
incomplete  specification  at  intermediate  stages  of  detail  design 
Indentation  should  be  made  to  indicate  a  nested  construct; 
symmetrical  keywords  (such  as  if  -  endif)  should  be  at  the  same 
level  of  indentation,  and  statements  within  larger  constructs 
shall  begin  at  a  further  level  of  indentation  than  that  of  the 
enclosing  construct. 

3.3. 1.3  Examples 

The  following  pages  illustrate  the  use  of  Ada/PCL  at  an 
intermediate  level  of  detail  design. 


Exaaple  (1)  (due  to  Grady  Booch) : 
procedure  TEXT  is 

—  Body  author,  date,  revision  level  (rev.  level  of 

specification  part  followed  by  rev.  level  of  body) 
Traceability  references 

—  Short  description  of  unit  function,  e.g.,  "Process  Text" 


begin 


— >  ignore  leading  blanks 
if  line  to  be  centered  then 
— >  align  text 
— >  put  out  line 
elsif  line  is  blank  then 

— >  put  out  line 
elsif  not  in  fill  aode  then 
— >  put  out  line 
else  --  handle  word-by-word 
loop 

— >  get  a  word 
exit  when  no_aore_wcrds 
— >  put  out  word 
end  loop; 
end  if; 
end  TEXT; 
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Exaeple  (2)  (due  to  Hal  Hart) : 

With  GLOBAL. PACKET,  CTHEB.GLCEALS 
procedure  FORMATTER  is 

—  (Author,  Date,  Revision,  Description) 

while  MORE  PACKETS  IH  FORMATTER  loop 
CHK.FORMAT; 

SEHD_P ACKER; 
endloop; 
end  FORMATTER; 

procedure  CHK_FORMAT  is 

function  VALID  (HEADER)  return  boolean 
procedure  READER  (PACKER:  cut) 
function  bod?  VALID  is  separate 
procedure  body  READER  is  separate 


begin  CHK  FORMAT 

READER  (PACKET)  ; 
if  VALID  (HEADER)  then 

if  SEC_LEV  >  TSO_LEV  FIRST  then 
case  DISPO  is 

when  MSG  =>  — >  Beasseoble  to  forward 
when  CTL  =>  — >  Update  control  tables 
when  MOTES  =>  — >  Copy  to  log  file 
end  case; 

else  Signal  low  security  level 
end  if; 

exception  when  CASE_EBROH  =>  Signal  operator 
end  CHK_ FORMAT; 


3.3.2 

3.3.2. 1  Description 

The  Final  Design  Beview  is,  as  its  nane  implies,  the  last  step  of 
the  design  process.  Therefore,  it  is  mandatory  that  every 
reasonable  effort  be  made  to  ensure  that  the  design  developed  is 
an  acceptable  solution  to  the  problem  at  hand. 

A  set  of  reviews  is  recommended  for  the  Final  Design  Review.  The 
set  consists  of  (1)  a  walk-through  of  the  design,  (2)  a 
preprogramming  Ada  evaluation  (3)  another  review  of  traceability 
from  requirements  to  design,  and  (4)  a  design  philosophy  review. 

3. 3. 2. 1.1  Design, Walk-Through.  The  design  walk-through  is  a 
manual  simulation  of  the  system  designed.  Some  sample  inputs  are 
vicariously  processed  through  the  system  as  designed  on  paper. 

3.3.2. 1.2  Preprogramming  Ada  Evaluation.  There  are  several 
evaluations  that  should  be  made  by  the  designer  prior  to 
submitting  his  product  to  the  programmer.  Cne  is  the  uniqueness 
versus  overloading  of  names  or  identifiers  which  he  has  defined 
in  the  design.  Ada  does  support  overloading,  and  overloading  can 
be  used  very  advantageously  such  as  the  case  of  subprograms  which 
accomplish  identical  functions  but  on  different  structures  or 
types.  All  overloading  should  be  evaluated  to  insure  that  it  is 
intentional  and  that  it  will  net  cause  confusion  or  conflict  in 
any  of  the  places  in  which  it  may  be  referenced. 

Data  types  should  be  evaluated  tc  insure  that  duplicate  types 
have  not  been  introduced  inadvertently,  and  that  a  type  is  not 
being  used  for  several  purposes  which  may  conflict  or  permit 
undetected  errors.  An  evaluation  of  data  type  range  constraints 
should  be  made  in  relaticn  tc  performance.  K  ist  checking 
concerning  types  is  done  during  compilation.  However,  range 
constraints  may  necessitate  runtime  checks,  and  depending  on  the 
particular  compiler  being  utilized  and  the  particular  ranges,  may 
introduce  undesirable  overhead. 

In  multi-tasking  designs  the  allocation  of  entries  to  specific 
tasks  should  be  carefully  evaluated.  Ada  supports  a  variety  of 
strategies  for  interprocess  communication.  Careful  evaluation 
must  be  made  to  insure  that  the  proper  strategy  has  been  selected 
for  each  instance  of  interprocess  communication.  A  good 
discussion  of  interprocess  connunicaticn  in  Ada  is  found  in 
"Tutorial  on  Ada  Tasking"  by  Stephen  A.  Schuman.  . 

3 . 3 . 2 . 1 . 3  S53Uil5»enis-icz£esign_Tr, cea^iliti .  A 
description  of  Reguirements-to-Design  Traceability  is  provided  in 
step  3.2.7  of  architectural  design. 

3. 3. 2. 1.4  Design  Philosophy  Review.  Oftentimes  the  original 
designers  of  a  system  are  not  available  to  assist  with 
maintenance  changes.  Therefore,  the  programmers  and  analysts 
that  maintain  a  system  in  production  are  often  at  a  disadvantage. 


98 


This  is  particularly  true  when  there  is  neither  sufficient 
documentation  nor  expertise  available  to  aaintenance  personnel. 
Even  when  system  documentation  is  available,  it  does  not  always 
provide  the  maintenance  personnel  with  enough  information  about 
the  design  philosophy. 

During  the  design  philosophy  review,  the  designer  (s)  should 
review  the  overall  design  and  document  the  design  philosophy  that 
was  utilized  to  make  major  design  decisions.  This  will  result  in 
a  Design  Philosophy  Document  to  be  used  and  maintained  after  the 
system  is  in  production. 

• 

3. 3. 2. 1.5  Itgratiye_pesjgn  Process.  The  designer  should 
correct  any  problems  identified  by  the  review  process  above. 
Appropriate  steps  within  the  entire  design  should  be  repeated  as 
required  to  correct  the  problem  (s)  identified. 

3. 3. 2. 2  Guidelines 

3. 3. 2. 2.1  Design,  Walk-Tbrcug.h. 

a.  Invite  all  the  designers  to  the  walk-through. 

b.  Designate  a  chairperson  to  preside  over  the  walk-through 
and  resolve  differences. 

c.  Conduct  the  walk-through  in  a  place  as  free  from 
disturbances  and  interruptions  as  possible. 

d.  Consider  inviting  a  user/custcmer  representative  that 
has  a  good  understanding  of  the  problem  being  solved  by 
the  design. 

e.  Select  some  good  sample  inputs  to  be  vicariously 
processed  (walked)  through  the  system.  The  inputs 
selected  should  (as  a  whale)  exhibit  characteristics 
that  will  test  each  function  of  the  system. 

f.  Develop  desired  outputs  for  each  input  to  be  walked 
through  the  system. 

g.  Document  the  problems  encountered  as  inputs  are  walked 
through  the  system. 

h.  Follow  up  on  each  problem  discovered  in  subsequent  walk¬ 
throughs. 

3. 3. 2. 2. 2  fiepiogxaf fling_i^§_Jvaiua tign. 

a.  Obtain  a  complete  cross  reference  list  of  all 
identifiers  or  names  utilized  in  the  design. 

b.  Examine  each  instance  of  overloading  to  prevent 
ambiguous  references  or  any  possible  conflict  or 
confusion. 
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c.  Exaaine  the  uses  of  each  data  type  to  insure  that 
sufficient  types  have  been  introduced  and  that  no  types 
have  been  inadvertently  duplicated. 

d.  In  light  of  perforaance  reguirenents,  evaluate  data 
types  for  runtiae  overhead  they  Bay  introduce. 

e.  when  collections  of  data  are  being  passed  as  paraaeters, 
consideration  should  be  given  to  using  records 
containing  the  collections  and  passing  access  values  to 
indicate  the  record.  This  can  reduce  paraaeter  passing 
overhead  when  carefully  done. 

f.  In  aulti-tasking,  the  preferred  aetbod  of  protecting 
critical  code  is  within  the  ndo...endN  of  a  rendezvous, 
so  as  to  be  clearly  evident  during  aaintenance. 

However,  in  a  feu  cases  in  a  nultipxocessor  environaent, 
when  there  is  a  considerable  aaount  of  critical  code  and 
when  it  is  desirable  tc  aaintain  two  threads  of 
execution  for  perforaance,  a  scheae  whereby  the  critical 
code  is  placed  between  two  different  rendezvous  nay  be 
used.  These  cases  aust  be  clearly  coaaented,  as 
protection  is  only  supplied  by  prograaaer  convention  and 
aust  not  be  violated  during  aaintenance. 

g.  In  aulti-tasking,  evaluate  all  accesses  to  shared  data 
to  insure  that  all  accesses  are  properly  synchronized 
and  that  all  critical  cede  is  properly  protected  by  in 
an  appropriate  rendezvous. 

h.  Evaluate  all  entry  calls  and  accept  statenents  to  insure 
that  an  appropriate  strategy  has  keen  properly  used  for 
each  interprocess  conunication. 

i.  When  task  activation  and  teraination  is  used  in  a 
systea,  a  careful  review  aust  be  Bade  of  task 
dependencies  to  ensure  that  deadlock  will  not  occur. 

3 . 3 . 2 . 2 . 3  isaaiie ag nisrisris sisji-li jssaiiliii  •  The 

guidelines  for  traceability  are  provided  in  step  3. 2. 7. 2. 


An  exaaple  of  a  reguireaents-tc-design  traceability  natrix  is 
provided  in  step  3.2.3.  A  suggested  outline  for  the  Design 
Philosophy  Document  is  provided  below. 
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3*3.2. 2.4  Ps§i3B-fiil2S2Bl!I_SSXiS3! 


a.  Docuaent  the  philosophy  behind  najor  design  decisions. 
Specifically,  give  reasons  for  the  following: 

-  Overall  structure  of  systea 

-  Ada  packaging 

-  Concuxrency/Iasking 

-  Hardware  selections 

-  Data  Structures  (including  files,  data  bases, 
stacks,  queues,  lists,  etc.). 

b.  Docuaent  strategies  used  and  how  they  iapacted  design 
(e.g.,  transfora  analysis,  transaction  analysis,  etc.). 

c.  Develop  a  list  of  design  adaonitions  (e.g.,  strength  of 
design,  weakness  of  design,  static  design  areas,  dynaaic 
design  areas,  and  suggestions  for  iaproveaent) . 

d.  Integrate  all  design  philosophy  docunentation  into  a 
Design  Philosophy  Docuaent. 

e.  Follow  up  on  any  probleas  that  night  arise  as  a  result 
of  this  final  review  of  the  design  philosophy. 
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3  -4  fA£X_2II-=-l£l-.fi££J££..E££J2£2£2 

a.4.i  fiassiiBiisfl 


The  output  of  design  sust  be  organized  into  an  Ada  Design 
Docunent.  This  docuaent  will  be  given  to  the  isplesentation  teas 
when  progressing  begins. 

3.4.2  Sai3sli£S3 

Organize  the  Ada  Design  Docuaent  according  to  the  outline  below: 

I.  Design  Philosophy  Dccuaent 

II.  Design  Graphic  Illustrations 

A.  Systes  Chart 

B.  Structure  Chart 

C.  Packages  Chart 

D.  u*  Chart 

B.  logical  Data  Structures  Hodel 

P.  Jackson  Data  Structures 

G.  Beguiresents-toEesign  Traceability  Matrix 

III.  Ada  Bepresentation  of  Systes. 


CHAPTEB  4 


Ada  EBVE1CPHEHT  STANDARDS 


4.1  ISX1SMSIIS1! 

Language  proliferation  has  been  one  of  the  CoD's  most  significant 
software  problems.  Custom  languages  and  compilers  have  been 
developed  "on  the  fly"  for  individual  projects.  Often,  the 
languages  and  compilers  have  been  developed  hastily.  This  has 
resulted  in  project  failures  and  unsatisfactory  results. 

Short-term  and  long-term  solutions  to  the  language  proliferation 
problem  have  been  developed.  The  short-term  solution  was  the 
establishment  of  a  set  of  seven  programming  languages  to  be  used 
for  the  development  of  all  Do£  software.  Unfortunately,  the 
seven  languages  of  the  standard  set  do  not  have  all  of  the 
features  needed  for  the  development  of  DoD  software. 

The  long-term  solution  was  determined  to  be  a  conversion  to  one 
common  programming  language.  Eenefits  from  conversion  to  a 
single  common  language  were  estimated  at  over  $100  million  per 
year.  The  DoD's  requirements  for  one  common  language  were 
expressed  in  the  Steelman  document.  In  meeting  the  Steelman 
requirements,  the  designers  of  Ada  have  created  a  large  and 
complex  language  with  powerful  constructs  and  semantic  subtleties 
that  offer  ample  opportunities  for  failures  as  well  as  successes. 

Although  Ada  was  initially  intended  to  be  the  implementation 
vehicle  for  embedded  real-time  systems,  current  experience  and 
interest  indicate  that  the  language  will  be  applied  to  a  much 
wider  problem  domain.  We  expect  that  Ada  will  be  used  in 
scientific  and  business  applications  in  addition  to  the  expected 
applications  in  avionics,  communications,  and  command/control. 
Further,  there  is  interest  in  Ada  as  a  requirements  and  design 
language  and  as  a  hardware  description  language  for  designers  of 
digital  systems.  In  short,  Ada  is  seen  by  many  as  a  potential 
"universal  language"  for  software  engineering. 

Ada's  newness,  size,  complexity,  and  global  appeal  make  it 
essential  that  a  good  set  of  Ada  development  standards  be 
implemented  and  enforced.  Unless  Ada  devlopment  standards  are 
applied,  designers  and  programmers  with  varying  backgrounds  will 
be  developing  Ada  systems  with  many  variations  of  style  and 
maintainability.  Therefore,  an  initial  set  of  Ada  Development 
Standards  has  been  created  as  a  part  of  the  effort  associated 
with  the  Ada  Capability  Study  contract.  The  standards  developed 
have  been  categorized  as  follows: 
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1.  Template  for  Ida  Coapilation  Units 

-  Design 

-  Programming 

B.  Preferred  Programming  Practices 

-  Documentation 

-  Basic  Constructs 
Declarations 

-  Baintainabilit y 

-  Basing  Conventions 

-  General  Coding  Conventions 

One  important  category  not  listed  above,  for  which 

standardization  is  essential,  is  portability.  The  article,  Ada- 
European  Guidelines  for  the  Portability  of  Ada  Programs,  by 
Bissen,  Ballis,  Hichman,  and  others,  that  appeared  in  the 
Harch, April  1982  issue  of  Ada  letters,  provides  a  set  of 
recommended  standards  for  Ada  portability. 


«*2  5I1MAMS 


Ida  developaent  standards  address  both  the  design  and 
iapleaentation  phases  of  systea  developaent.  The  "Template  for 
Ida  coapilation  Units"  section  includes  design  and  progressing 
standards,  ill  other  sections  consist  of  only  progressing 
standards. 

There  are  two  types  of  Ida  development  standards — requirement  and 
guideline.  Each  type  is  defined  below: 

Bequireaent  -  reguires  coaplete  adherence  by  the 

designer/prograaser  and  shall  be  enforced  by 
the  project  sanager 

Guideline  -  suggests  adherence  but  deviation  is  peraitted 
when  designer/prograaser  can  show  proper 
justification. 

Baintainability  is  the  these  that  peraeated  the  creation  of  the 
Ida  Developaent  Standards;  perforaance  was  not  a  consideration. 
However,  realizing  that  Ida  will  be  used  in  a  real-tine,  embedded 
systeas  environment,  there  nay  be  cases  where  the  project  sanager 
will  choose  to  relax  adherence  to  the  standards  for  perforaance 
reasons.  It  is  suggested  that  these  coaproaises  be  aade  only 
after  hard  evidence  supporting  then  is  established  and 
docuaented. 

4  •  2 .  i 

The  aaintainability  of  a  prograa  is  directly  related  to  its 
structure.  Ida  provides  soae  prograa  structuring  capabilities 
that  nay  be  used  advantageously  cr  detrimentally.  The  purpose  of 
the  standards  in  this  section  is  to  direct  the  developers 
(designers  and  progranaers)  in  their  use  of  (1)  the  Ida 
structuring  capabilities  and  (2)  basic  design  heuristics. 

4. 2. 1.1  Template  Design  Standards 

The  Ida  designer  aust  be  faailiar  with  the  Ida  concepts  of 
subprograa,  packaging,  nesting,  and  local  variables/visibility. 
Additionally,  the  Ada  designer  should  be  faailiar  with  soae  of 
the  basic  design  heuristics  that  facilitate  developaent  of  gccd 
maintainable  systeas  (regardless  of  the  iapleaentation  language) . 
This  subsection  provides  soae  design  standards  that  will  assist 
the  designer  in  structuring  a  prograa  for  aaintainability. 

4.2. 1.1.1  Control  Boutine/Package  Services.  It  is  recoaaended 
that  Ada  systeas  be  designed  according  to  the  principles  of 
object-oriented  design  and  inforaation  hiding,  following  these 
principles  will  result  in  a  design  that  encapsulates  data 
structures  and  all  their  operations  (services)  within  Ada 
packages. 


The  design  aust  integrate  the  package  services  within  a  total 
systea.  Ideally,  the  package  services  will  he  called  as  needed 
by  control  routines  within  the  systea  hierarchy.  The  control 
routines  are  the  subprograas  responsible  for  accoaplishing  and 
coordinating  the  activities  of  a  given  function.  The  advantages 
expected  froa  the  application  cf  this  concept  are: 

A.  Siaplicity  -  derived  froa  hiding  data  structures  and 
design  decisions. 

8.  Clean  interfaces  to  black  boxes  (package  services) . 

C.  Hell-partitioned,  highly  factored  systems. 

D.  Limited  nesting  and  visibility  problems. 

E.  Support  of  aaintainability. 

In  order  to  achieve  these  advantages,  the  following  guidelines 
have  been  established. 


Guideline 


Guideline 


Guideline 


Guideline 


Develop  Ada  packages  that  provide  services  for 
a  given  data  structure. 

Use  the  infcraation  hiding  concept  to  hide 
data  structures  and  design  decisions  -  provide 
services  that  conceal  the  data  structures  and 
internal  details  from  the  calling  subprogram. 

Use  Private/Iiaited  Private  constraint  on  data 
structures  to  support  information  hiding  and 
abstract  data  types  during  design. 

Use  Limited  Private  constraint  when 
comparisons  and/or  assignments  of  data  could 
produce  inaccurate  results. 


4.2. 1.1.2  Limited  Nesting.  Rethodical  application  of  structured 
programming  techniques  nay  lead  to  the  creation  of  programs  with 
many  levels  of  nested  subprograms.  Extensive  nesting  tends  to 
reduce  the  benefits  of  methodology  in  the  maintenance  phase  of 
the  software  life  cycle.  The  article.  Nesting  in  Ada  Programs  is 
for  the  Birds,  by  Clark,  Hileden,and  Holf,  that  appeared  in  the 
November  1980  issue  of  Sigplan  Notices,  outlines  these  problems 
with  respect  to  Ada  and  proposes  a  means  to  completely  avoid 
nesting.  However,  we  believe  a  disciplined  utilization  of 
nesting  should  be  available  to  the  software  designer. 


Guideline  -  Avoid  subprogram  nesting  whenever  possible; 

exploit  packages  and  separate  compilation  to 
enhance  readability  and  maintainability. 

Beguirement  -  Subprogram  nesting  shall  be  limited  to  at  most 
three  levels  except  as  approved  on  a  case-by- 


case  basis  by  the  manager  responsible  for  the 
project. 

4. 2. 1.1. 3  Local  Variables  and  Visibility.  The  structured 
programming  purist  imposes  severe  constraints  on  access  to  data 
within  each  subprogram,  ill  variables  accessed  should  be  either 
local  to  the  subprogram  or  parameters  to  the  routine.  For 
embedded  systems  design,  this  may  be  rather  inconvenient;  for 
example,  access  to  several  global  state  variables  is  often  a 
necessity. 

Guideline  -  avoid  references  to  global  variables.  If  such 
references  are  necessary,  the  variable 
references  should  be  qualified  by  the  name  of 
the  routine  in  which  the  variable  is  actually 
declared,  sc  that  the  global  reference  is 
explicit. 

Seguirement  -  Each  variable  shall  be  declared  locally  to  the 
scope  of  its  use  in  order  to  minimize 
introduction  of  errors  by  erroneous 
modification  of  data. 

4.2. 1.1.4  Single  Entry/Single  Exit.  The  single  entry/single 
exit  concept  is  a  pre-Ada  structured  programming  concept  that 
supports  simplicity,  consistency,  and  maintainability  of  code. 

Beguirement  -  All  Ada  subprograms  shall  have  one  entry  and 
one  exit. 

4.2. 1.1.5  Size.  The  size  of  each  Ada  design  unit  is  important 
in  terms  of  maintainability.  Studies  have  shown  that  persons  can 
cope  with  multiple  small  problems  easier  and  more  efficiently 
than  they  can  cope  with  one  large  problem.  Considering  this,  the 
size  of  each  Ada  design  unit  bcdy  should  be  limited  to  a 
reasonable  number  of  executable  statements. 

Guideline  -  Each  Ada  design  unit  body  should  not  exceed 
200  lines  of  executable  code. 

4.2. 1.2  Template  Programming  Standards 

This  subsection  includes  programming  standards  to  be  applied 
during  the  implementation  phase.  These  standards  support  the 
development  of  good,  maintainable  programs  and  the  implementation 
of  development  strategies  and/cr  test  plans. 

4.2. 1.2.1  Ose  of  "is  separate" 

Guideline  -  Ose  "is  separate"  to  defer  the  implementation 
of  lower  level  details  in  the  top-down 
development  of  a  software  system. 

Guideline  -  The  use  of  "is  separate"  should  be  well 

documented  if  the  separate  compilation  unit  is 
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sensitive  tc  global  data  (within  the  context 
of  nesting). 

4. 2. 1.2. 2  Ose  of  "with" 

Requirement  -  Each  routine  shall  have  access  only  to 

packages  required  for  implementation  of  the 
routine. 

4. 2. 1.2. 3  Order  of  Declarations 

&  uniform  approach  to  declarations  of  objects  in  Ada  is  necessary 

to  promote  readability  and  ease  of  maintenance. 

Requirement  -  All  declarations  possessing  the  same 

characteristics  shall  be  grouped  together  and 
commented  accordingly.  For  example,  all 
COHSTANTS  shall  be  together,  all  TYPES 
together,  etc.  Accordingly,  all  SOBTYPSS 
shall  immediately  follow  (and  optionally  be 
indented  from)  their  respective  TYPES.  A 
blank  line  should  be  used  to  separate  the 
groups. 

Requirement  -  If  constants  of  a  user-defined  type  are 

required  they  should  be  grouped  together  into 
a  separate  CONSTANT  declaration  immediately 
following  the  TYPE  declarations. 

Requirement  -  within  each  group  named  above  (except  TYPES) , 
all  identifiers  should  be  arranged 
alphabetically  by  name.  (This  is  difficult  to 
demand  for  TYPES,  for  which  meaningful  names 
and  elaboration  order  requirements  may 
preclude  alphabetic  arrangement.) 


CONSTANT  DECLARATIONS 


BUFFEB.SIZE  :  constant  :  =  ICO  ; 

PI  :  constant  :=  3.1416  ; 

RECORD_SIZE  :  constant  80  ; 

TYPE  DECLARATIONS 

type  REEK  DAYS  is  {  NONDAY ,  TUESDAY,  WEDNESDAY, THURSDAY, 

FRIDAY,  SATURDAY,  SUNDAY  )  ; 

type  MONTH  NANS  is  (  JAN,  FEE,  BAR,  APR,  HAY,  JUN, 

JUL,  AUG,  SEP,  OCT,  NOY,  DEC  )  ; 

subtype  FIHST_QTR  is  BONTH_NAHE  range  JAN  ..  BAR  ; 

type  DATE  is 
record 

HONTH  :  HONTH  NAHE  ; 

DAY  :  INTEGER  range  1  ..  31  ; 

YEAR  :  INTEGER  range  1900  ..  1999  ; 

end  record  ; 

CONSTANTS  OF  USEH-DEFINED  TYPES 

FIBST.DAY  :  constant  WEEK  DAYS  BONDAY  ; 

LAST.DAY  :  constant  HEEK.DAYS  :=  SUNDAY  ; 

VARIABLES 

ANNIVERSARY  :  CATE  ; 

ANSWER  :  BOOLEAN  :  =  FALSE  ;  —  INIT.  IN  DECLARATICN 

HOFL  :  INTEGEH  ;  —  READ  OE  FREE  LIST 

RECORD  TYPE  :  INTEGER  ; 


Figure  4.2.1  Order  of  Declarations  Exaaple 


4.2.2  Preferred. Prograaming  Practices 


The  enforcement  of  a  good  set  cf  programming  standards  will 
foster  understanding  and  consistency  of  the  code  developed. 
Understanding  and  consistency  'cf  the  code  will  contribute  to 
52ifi£§i23bilit£,  the  salient  theme  behind  the  development  of  the 
standards. 

4.2.2. 1  Documentation 

4.2.2. 1.1  Preamble  Documentation 

Requirement  -  Every  procedure,  function,  or  package  shall 
include  a  preamble  placed  between  the  name 
declaration  and  the  source  code. 

Requirement  -  Every  preamble  shall  include  at  least  the 
following  items: 

*  Name  of  Dnit 

*  Abstract — short  description  of  purpose 

*  Processing  description — 
algorithms/literature  references 

*  Shat  errors  are  handled  and  how — 
exception/status  returns 

*  Definitions  of  all  input  and  output 
variables 

Requirement  -  when  a  particular  hardware  or  software 

configuration  for  compilation  and  linking 
(host  processor)  or  execution  (target 
processor)  is  required  by  a  package  or 
routine,  that  dependency  must  be  detailed  in 
the  preamble. 


procedure  GCD  (  X, 

X  :  in  INTEGER  ; 

CCMFACTCB  :  out  INTEGER  )  is 

—  **************************************************************** 

Mnemonic  :  GCD 

—  Osage  :  compute  greatest  common  factor  of  two  integers 

—  Author  :  Euclid 

Host 

—  machine  :  Cray-4 

o/s  :  CP/M 

Target 

machine  :  Intel  80286 
o/s  :  MP/M  286 

Abstract  : 

Given  two  integers  X  and  X  as  input,  the  greatest  common 
factor  of  X  and  X  is  computed  and  returned  to  the  caller 
through  the  formal  cut  parameter  CCMFACTOB. 

Processing 

«  description  of  algorithm  » 

«  error  conditions  with  exceptions  and  messages  » 

—  **************************************************************** 

<<  body  of  procedure  here  >> 


Figure  4. 2. 2-1  Preamble  Example 


4. 2. 2. 1.2  Comments 

Requirement  -  Comments  associated  with  structured  statements 
shall  align. 

Beguirement  -  Comments  appended  at  the  end  of  a  line  and 

continued  to  successive  lines  shall  be  written 
so  the  continued  comment  fragments  physically 
align  under  the  beginning  comment  fragment. 
Subsequent  statements  should  not  begin  until 
after  the  comment  has  been  completed. 

4. 2. 2. 2  Basic  Constructs 

Bohm  and  Jacopini  proved  that  all  computer  programs  may  be 
written  using  only  three  basic  constructs.  These  three 
constructs  are  described  on  the  following  page  using  flowchart 
symbology . 


Cf  course,  Ada  supports  these  three  constructs.  Ada  also 
supports  extensions  to  the  selection  and  iteration  constructs. 

The  selection  is  supported  in  Ada  by  the  "if-then",  "if-then- 
else",  and  "case"  constructs.  The  iteration  ("do  while")  is 
supported  by  the  "while/for  condition  loop"  construct  in  Ada.  An 
infinite  iteration  is  simply  suFFOtted  by  the  "loop"  (without  the 
"while  condition")  construct.  A  "do  until"  iteration,  in  which 
the  action  is  performed  within  the  loop  before  the  condition 
check,  is  supported  in  Ada  by  a  combination  of  the  loop  and  exit 
constructs  (exit  must  be  placed  inside  loop  to  be  executed  when  a 
condition  is  true)  . 

The  sequence  construct  is  general  in  nature  and  will  not  be 
addressed  specifically  in  the  standards  below.  However, 
standards  have  been  developed  for  the  selection  and  iteration 
constructs  and  their  Ada  extensions. 

4. 2. 2. 2.1  Selection  Standards 

Requirement  -  The  if-then  construct  shall  only  be  used  when 
there  is  an  action  associated  with  the  true 
condition  and  no  action  associated  with  the 
false  condition. 

The  if-then-else  construct  may  also 
be  used  when  there  is  only  an  action 
associated  with  a  true  condition  by 
placing  "null"  after  the  else. 


Note: 


Guideline 


-  Nested  if's  are  preferred  over  compound 
complex  single  if  statements. 

Requirement  -  There  shall  fce  at  most  three  levels  of  nested 
if's. 

Guideline  -  The  case  statement  is  preferred  over  a  series 
of  if  statements  whenever  appropriate. 

Requirement  -  Statements  associated  with  the  if  statement 
must  align  and  be  indented  consistently,  but 
by  at  least  two  spaces.  This  standard  is 
illustrated  by  Figure  4.2. 2-2. 

Requirement  -  The  'then*  associated  with  the  true  condition 
of  an  if  statement  must  be  coded  on  the  same 
line  as  the  'if'.  The  action  (s)  associated 
with  a  true  condition  must  start  on  the  line 
immediately  below  the  if.  Figure  4. 2. 2-2 
illustrates  this  standard. 

Requirement  -  The  statement  elements  associated  with  the 
case  statement  shall  align,  and  be  indented 
consistenly,  but  by  at  least  two  (2)  spaces. 
Figure  4. 2. 2-3  illustrates  this  requirement. 

4. 2. 2. 2. 2  Iteration 

Requirement  -  The  "do  while"  iteration  shall  be  coded  using 
the  'for'  or  'while'  condition  with  the  'loop' 
verb.  (See  Figure  4. 2. 2-4.) 

Requirement  -  statements  associated  with  the  loop  statement 
and  all  variants  of  the  loop  statement  shall 
be  indented  consistently,  but  by  at  least  two 
spaces.  This  standard  is  illustrated  by 
Figure  4. 2.2-4. 

Requirement  -  The  'do  until'  iteration  (action  performed 

before  condition  check)  shall  be  implemented 
with  a  lcop  statement  and  an  'exit  when' 
statement  within  the  loop.  This  standard  is 
illustrated  by  Figure  4. 2. 2-5. 

Requirement  -  Avoid  using  multiple  exit  statements  in  a 
loop. 

Requirement  -  The  infinite  loop  shall  be  implemented  with  a 
loop  statement  without  any  conditions.  (See 
Figure  4. 2. 2-6.) 
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if  INDENT  then 

CHECK_LEFT_MARGIN; 
elsif  OUTDENT  then 
BIGHT_SHIFT; 
else 

CABBIAGE  RETURN ; 
CONTINOE~SCAN ; 
endif ; 


Figure  4. 2. 2-2  Bxaaple  cf  IF  Statement  Indentation 


case  TODAY  is 
when  HOIDAY  »> 

COMPOTE  INITIAL  BALANCE  ; 
when  TUESDAY  ..  THURSDAY  *> 
G£NEBATE_REPOBT (TODAY)  ; 
when  FRIDAY  *> 

COHPUTE_CLOSING  BALA NCE  ; 
when  SAToicAY  ..  SUNDAY  »> 
null  ; 
end  case  ; 


Figure  4. 2. 2-3  Case  Exanple 


for  I  in  1  ..  10  loop 
SUM  :=  SUM  ♦  TABLE  (I) ; 
end  loop; 

INDEX  :=  1 

while  INDEX  <=  20  loop 

if  TABLE  (INDEX)  >  MAX  then 
MAX  TABLE (INDEX)  ; 
end  if 

INDEX  :=  INDEX  +  1; 
end  loop 


Figure  4. 2. 2-4  Ada  "Do  While"  Loops 


PEBPETUAL_LCCP  :  — note  indentation 

loop  — from  loop  identifier 

COUNT  :=  COUNT  +  1; 

GET  (TEBP) ; 

PUT  (TEHP)  ; 
end  loop; 


Figure  4. 2. 2-6  Ida  Infinite  Loop 


4. 2. 2. 3  Declarations 

This  subsection  specifies  those  Ada  coding  practices  which  apply 

to  the  use  of  declarations. 

4. 2.  2. 3.1  coBaenting  Declarations 

Requirement  -  Each  constant,  type  variable,  and  field 

identifier  declared  shall  be  accompanied  by  a 
brief  COEHENT  if  the  mnemonic  identifiers  are 
not  self-explanatory. 

4. 2. 2. 3. 2  Program  Hessages 

Requirement  -  All  coded  program  messages  shall  be  declared 

as  program  constants  and  the  messages  shall  be 
identified  in  the  "OUTPUT"  or  "EBBGR 
CONDITIONS"  section  of  the  preamble. 

4.2. 2. 3.-3  Declaration  Formatting 

Requirement  -  Every  declaration  shall  begin  cn  a  new  line 
and  shall  be  aligned  with  all  preceding 
declarations. 


Guideline  -  It  is  recommended  that  each  variable  of  a 
declaration  appear  on  a  separate  line. 

Example:  X, 

Y  :  INTEGER 

Guideline  -  All  constants  and  variables  should  be  an 

instance  of  a  named  type;  in  particular,  array 
and  record  objects  should  reference  explicit 
type  names. 

4. 2. 2. 3. 4  Use  of  Constants 

Requirement  -  All  SCALAR S  that  (1)  are  used  in  more  than  cne 
instance  within  the  same  context,  (2)  are 
known  scientific  or  engineering  constants,  or 
(3)  have  associated  dimensions  such  as  buffer 
size,  terminal  width,  etc.  that  are 
susceptible  to  change  shall  be  specified  as 
named  program  constants. 

Guideline  -  The  upper  bounds  of  all  static  arrays  should 
be  specified  by  program  constants. 

4. 2. 2. 4  Haintainability 

Guideline  -  Comments  should  be  composed  at  the  same  time 
that  code  is  composed. 

Guideline  -  Functions  should  avoid  side  effects.  For 

example,  the  value  of  a  global  variable  should 
not  be  changed.  Any  exceptions  should  be 
conspicuously  documented. 

Guideline  -  All  type  declarations  should  include  bounds 

that  constrain  variables  to  the  expected  range 
of  values.  For  example,  if  the  range  of  an 
integer-valued  type  is  known  an  appropriate 
type  declaration  should  include  those 
constraints: 

type  TWENTIETH_CENTURY  =  1900  ..  1999  ; 

Guideline  -  Separate  types  should  be  declared  specific  to 
their  use.  The  type-checking  capability  of 
Ada  may  be  exploited  if  new  types  are  declared 
for  each  use,  although  some  types  may  overlap. 

type  ORANGE.QNTY  is  new  NATURAL  ; 
type  PECAN_CNTY  is  new  NATURAL  ; 

Requirement  -  Each  statement  shall  begin  on  a  separate  line. 


Requirement 

Requirement 

Guideline 

Guideline 

Guideline 

Guideline 

4. 2. 2. 5  Naming 
Guideline 

Requirement 

Requirement 

Guideline 

Guideline 


-  At  least  one  space  shall  appear  before  and 
after  all  relational  operators,  Ada  reserved 
words,  identifiers,  and  arithmetic  operators. 

-  Ose  explicit  assignments  in  aggregates  in  lieu 
of  positional  assignments. 

-  Use  attributes  instead  of  hard  coding  numeric 
literals  whenever  possible. 

-  Range  constraints  on  arrays  should  be 
specified  using  named  constants  or  attributes 
of  enumeration  types. 

-  Use  parentheses  in  expressions  to  enhance 
clarity. 

-  Write  code  with  lots  of  white  space  to  enhance 
readability.  Avoid  bunching  variable  names, 
relational  operators,  subscripts  together. 

Conventions 

-  Use  meaningful  names  for  all  types,  objects, 
subprograms,  and  tasks. 

-  A  consistent  naming  convention  shall  be 
established  for  all  objects  of  interest  at  the 
outset  of  the  project.  This  should  form  the 
basis  for  the  project  data  dictionary. 

-  The  use  of  overloaded  names  for  subprograms 
shall  be  restricted  to  those  instances  in 
which  subprograms  perform  semantically 
identical  operations  on  differing  data  types. 

-  If  a  task  has  a  single  entry  point,  it  is 
recommended  that  this  entry  be  named 
"ENTHY_POINT",  or  sone  similar  name;  this 
avoids  the  introduction  of  awkward  names  in 
such  contexts. 

-  Use  some  naming  convention  to  distinguish 
access  types  from  other  data  and  routine  names 
which  may  be  used  as  "qualifiers",  for 
example,  if  access  variable  names  are  given  a 
consistent  suffix  "_ptr",  then  all  access 
variable  references  are  textually  emphasized. 

-  The  names  of  types  and  constants  should 
reflect  their  use.  A  value  used  in  more  than 
one  context  should  have  an  equivalent  set  of 
names  and  declarations.  An  example  is 
provided  below. 


Guideline 


NUMBEB_OF_l!C!JTBS  :  constant  :=  12  ; 

DOZEN  :  constant  :  =  12  ; 

Guideline  -  The  naaes  of  types  and  objects  should  not  be  a 
sinple  recapitulation  of  their  values.  For 
example,  one  should  avoid  declarations  such  as 

ZERO  :  constant  :=  0  ; 

Guideline  -  Avoid  use  of  the  "use  clause"  when  multiple 

packages  are  imported  and  local  variables  have 
sane  naaes. 

4. 2. 2. 6  General  Coding  Conventions 

This  subsection  specifies  general  coding  practices  which  apply  to 

the  coding  of  Ada  program  statements. 

4. 2. 2. 6.1  Label  and  GO  TO 

Guideline  -  Label  and  GO  TC  statements  should  be  used 

sparingly.  Their  use  should  be  restricted  cr 
controlled  within  the  boundary  of  one  block. 
Generally,  a  GO  TO  should  only  branch  to  the 
beginning  or  end  of  a  block  from  a  point 
within  the  block.  Label  and  GO  TO  statements 
should  not  be  used  to  transfer  control  from 
block  to  block  and  should  not  traverse  large 
segments  of  code. 

4. 2. 2. 6. 2  Dpper  and  Lower  Case 

Requirement  -  For  uniformity,  all  declared  items  shall  be 

capitalized  and  all  reserved  words  shall  be  in 
lower  case. 

4. 2. 2. 6. 3  Program  Units 

Requirement  -  Each  program  unit  shall  be  preceded  by  at 
least  one  blank  line. 

Requirement  -  The  end  which  concludes  a  subprogram  body, 
package,  specification,  package  body,  task 
specification,  or  task  body,  shall  always  be 
followed  by  the  name  of  the  program  unit. 

Requirement  -  Statements  associated  with  blocks  shall  align 
and  be  indented  consistently,  but  by  at  least 
two  spaces.  This  standard  is  illustrated  by 
Figure  4. 2. 2-7. 

4. 2. 2. 6. 4  Procedure  and  Function  Subprograms 

Requirement  -  If  the  procedure  declaration  and  associated 
parameter  list  does  not  fit  readily  on  one 
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line,  the  parameter  list  shall  be  aligned  and 
coded  with  one  parameter  per  line. 

acquirement  -  The  begin  and  end  surrounding  a  subprogram 
body  shall  be  aligned  under  the  subprogram 
specification.  All  other  statements  shall  be 
indented  consistently,  but  by  at  least  two 
spaces. 

Guideline  -  Parameters  should  be  grouped  together 

according  to  their  function  as  either  in,  cut, 
or  inout. 

Requirement  *  In  any  given  call  to  a  subprogram,  all 

parameter  references  shall  be  of  a  consistent 
type;  i.e.,  positional  and  keyword  parameter 
references  shall  not  be  mixed  in  a  given  call 
to  a  subprogram. 
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SHIP  : 
declare 

TEHP  :  INTEGER  ; 
begin 

T1BP  :«  V; 

V  •  3  fl  • 

0  :»  TEMP; 

end  SHIP; 

Figure  4. 2. 2-7  Bxaaple  of  Block  Indentation 


function  FACTOBIAL  (  N  :  NATOBAL  )  return  FLOAT  is 
TEHP  :  FLOAT  ; 
begin 

if  I  *  1  then 
TEHP  s*  1.0  ; 
else 

TEHP  :=  FLOAT  (  N  )  *  FACTCBIAL  (  H  -  1  )  ; 

end  if  ; 
return  TEHP  ; 
exception 

end  FACTOBIAL  ; 


Figure  4. 2.2.8  Exanple  of  Function  Standards 


procedure  POSH  (  E  :  in  E1IHENT_TYPE  ;  S  :  inout  STACK)  is 
begin 

if  S. INDEX  »  s.SIZE  then 
raise  STACK_OVEHFLON  ; 
else 

S. INDEX  :*  S. INDEX  +  1  ; 

S. SPACE  (S. INDEX)  :=  E  ; 
end  if  ; 
end  POSH  ; 


Figure  4.2. 2-9  Exaaple  of  Procedure  Standards 


Guideline 


-  in  instances  in  which  fomal  parameters  nay  be 
given  highly  sneaonic  names,  the  use  of 
keyword  parameter  references  should  be 
exploited  to  enhance  readability  and  ease  of 
aaintenance. 

Beguireaent  -  Explicitly  identify  the  node  of  each  parameter 
in  a  call  (avoid  'in'  parameter  default). 

Beguireaent  -  Avoid  the  use  of  default  parameters  in 
procedures  and  functions. 

Q.2.2.6.5  Exceptions 

Beguireaent  -  The  exception  reserved  word  shall  align  under 
the  begin  of  the  appropriate  block. 

Beguireaent  -  Each  exception  choice  within  an  exception 
handler  shall  align  and  be  indented 
consistently,  but  by  at  least  two  (2)  spaces. 
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4.3  SSKiSSISl! 


&  ayriad  of  new  Ada  prograaaers  with  various  backgrounds  and 
varying  degrees  of  expertise  is  developing.  Therefore,  the  EoE 
■ust  recognize  that  Ada  prograas  will  differ  significantly  in 
style,  quality,  and  aaintainability  unless  Ada  developaent 
standards  are  iapleaented  and  strictly  enforced. 

The  iapleaentation  of  Ada  developaent  standards  nust  be  planned. 
Procedures  for  ensuring  that  standards  are  followed  should  be  in 
place  when  Ada  tecoaes  the  DoE's  official  prograaoing  language. 
Additionally,  certain  tools  should  be  developed  in  support  of  the 
standards. 

4.3.1  Tools  Heeded 

No  developaent  standard  will  be  successful  if  it  iapedes  the  work 
of  the  software  engineering  professional.  One  Beans  of  easing 
the  individual  iapact  of  a  standard  is  to  provide  aids  for  the 
use  of  such  a  standard.  The  following  toolset  is  a  partial  list 
of  aids  which  will  provide  enhanced  capabilities  for 
iapleaentation  and  aaintenance  personnel.  Note  also  that  there 
is  soae  overlap  in  the  functions  suggested,  leaving  soae 
flexibility  to  the  user. 

A.  An  enhanced  cross  reference  and  "use  table"  generator 
which  provides  a  aeans  to  resolve  variable  overloading 
in  each  subprograa. 

B.  An  "expand"  coapiler  pragma  to  replace  all  global  naae 
references  by  fully  qualified  naaes  in  the  text  of  a 
subprogram. 

C.  An  "eject"  pragma  to  control  pagination  in  the  coapiler 
listing  for  clarity. 

D.  A  "package  reference  expansion"  pragaa  to  list  the 
visible  part  of  a  referenced  package  in  the  declaration 
part  of  the  routine  in  which  the  reference  occurs,  with 
appropriate  notation  tc  indicate  the  expansion. 

E.  A  "pretty  print"  facility  which  enforces  as  auch'of  the 
developaent  standard  as  nay  be  automated,  and  notes  any 
violations  detected. 

4.3.2  Egg,  Cqqpjnued  aeseargh  ,  and|  pgvelopaent 

Any  standard  for  Ada  developaent  must  be  closely  related  to  a 
systeas  design  aethodology.  Many  problems  oust  be  solved  with 
relation  to  the  aethodology  such  as  a  "graceful"  incorporation  of 
the  Ada  tasking  aodel,  which  will  have  an  obvious  impact  on  the 
developaent  standards.  The  standard  itself  Bust  be  refined  in 
light  of  experience.  As  the  Ada  experience  base  grows,  new 
issues  relating  to  standards  will  arise  and  Bust  be  addressed  as 
they  occur.  Also,  the  iapact  cf  the  standard  on  programmer 


productivity  and  aaintainability  aust  be  assessed.  Soae 
restrictions  currently  in  the  preposed  standard  nay  be  relaxed 
once  a  sufficient  population  of  Ada-literate  prograaaers  and 
designers  exists.  Significant  work  reaains  in  the  area  of 
standards  relating  to  the  tiaely  introduction  of  architectural 
dependencies  in  the  design  process. 

4.3.3  iifigiiangs-g^jaa-tssslsEgSB^-staadards 

The  newness  of  Ada  contained  with  its  power  and  the  shortage  of 
appropriately  trained  personnel  aake  the  existence  of  a 
developaent  standard  a  practical  necessity.  The  standard 
presented  has  been  created  as  a  "first  order  approximation" , 
restricting  the  use  of  certain  novel  features  of  Ada  such  as 
overloading  and  paraaeter  associations  to  nodes  wore  closely 
reseabling  languages  in  current  use.  Cn  the  other  hand,  there  is 
little  said  in  regard  to  exceptions  and  tasking  as  effective  use 
of  these  features  reguires  soae  eapirical  evidence  to  support 
creation  of  reasonable  standards.  This  standard  should  be  viewed 
as  the  beginning  of  an  evolutionary  process  which  will  be  driven 
by  the  accuaulated  experience  in  the  use  of  Ada  as  well  as  growth 
in  the  population  of  Ada  language  users.  It  is  nost  important 
that  a  variant  of  this  standard  or  soae  other  standard  be  in 
place  before  the  availability  of  validated  compilers  so  that  a 
standard  may  develop  in  light  of  a  large  body  of  experience. 

This  would  be  of  benefit  to  developers  and  consumers  of  Ada-based 
software. 


CHAPTER  5 


METHODOLOGY  EXPERIENCES  AND  RECOMMENDATIONS 

5. 1  PBEFACE 

The  development  of  AIM  and  its  sutseguent  application  to  the 
redesign  of  a  message  switch  system  has  been  a  very  beneficial, 
learning  experience.  There  have  been  many  lessens  learned  as 
well  as  suggestions  and  ideas  foe  inpreving  AIM.  Three 
activities  that  have  been  aost  beneficial  in  teras  of  evaluating 
and  improving  AIM  are  briefly  described  below: 

1.  Initial  Application  of  AIM  -  As  soon  as  a  phase  of  AIM 
was  coapleted,  it  was  applied  by  the  design  teas.  This 
resulted  in  the  discovery  of  "bugs"  in  AIM  that  were 
iaaediately  corrected.  However,  soae  probleas 
identified  were  not  iaaediately  solvable.  These 
probleas  contributed  to  the  lessons  learned  on  this 
project. 

2.  Consultants'  Suggestions  and  Ideas  -  Consultants  frea 
industry  and  acadeaia  evaluated  AIM.  Their  evaluations 
resulted  in  aany  suggestions  and  ideas  for  iaproveaent. 
Soae  of  these  ideas  and  suggestions  have  already  been 
incorporated  into  AIM  while  others  are  addressed  later 
in  this  chapter  as  reccaaendations  for  iaproveaent  and 
reconmendations  for  further  research. 

3.  Continued  Methodology  Study  by  Chief  Methodology 
Engineer  -  The  chief  aethodology  engineer  has  continued 
to  study  methodologies  and  make  aodifications  to  AIM 
after  its  completion.  Soae  of  the  lessons  learned  and 
recommendations  addressed  later  in  this  chapter  evolved 
from  this  continued  study. 

The  reaainder  of  Chapter  5  addresses  (1)  the  lessons  learned  froa 
the  Ada  Capability  Study,  (2)  reccaaendations  for  improving  AIM, 
and  (3)  recommendations  for  further  research. 

5.2  WESSONS  {.EARNED 

Summaries  of  the  lessons  learned  from  the  Ada  Capability  Study 
are  provided  below. 

5.2.1  Importance. 9^  Using  a  Methodology 

Methodologies  provide  a  plan  or  road  map  for  systeo  development. 
Without  a  plan,  the  system  development  of  any  aajor  system  is 
more  susceptible  to  failure,  A  aethodology,  even  though  it  may 
only  be  a  framework  such  as  AIM,  forces  the  project  teaa 
personnel  to  think  about  the  problem  and  solution  in  an  organized 
manner.  In  the  words  of  one  of  our  cons  ‘ants,  "Any  methodology 
is  ninety  percent  good". 


125 


5.2.2  lM2lia££§_2£  _JJnaS£§£22di2S_iilS_£E2*lSl 


It  is  extremely  important  to  develop  an  understanding  of  the 
probleo  in  the  requirements  phase  of  system  development.  This  is 
true  regardless  of  the  type  of  system  being  developed  (i.e., 
business,  real-time,  scientific,  etc.) .  Once  a  good 
understanding  of  the  problem  is  developed,  the  design  process  is 
ready  to  begin. 

The  design  team  used  much  more  time  and  effort  than  originally 
anticipated  to  complete  the  requirements  phase.  However,  the 
feeling  is  that  the  extra  time  was  well  spent.  The  requirements 
analysts  developed  an  understanding  of  the  problem  that  reduced 
the  effort  required  during  the  design  phase. 

5.2. 3  Ose  of  Ada  as  an  BSL  Seduces. Design  and, Programming 
gf f or ts 

The  Ada  Requirements  Specifications  produced  during  the 
requirements  phase  eliminated  the  need  for  an  Ada  POL  expression 
of  the  system  during  the  design  process.  The  design  team  felt 
that  the  Ada  Requirements  Specifications  were  sufficient 
specifications  to  begin  program  development  once  architectural 
design  was  completed.  The  programming  effort  was  also  reduced 
because  the  frameworks  of  many  of  the  Ada  procedures  were 
established  during  the  requirements  phase. 

5.2.4  Lack  of  Integration  Eetween  Structured  Analysis 
and  structured .Design 

Structured  Analysis  and  Structured  Design  methodologies  do  not 
integrate  as  smoothly  from  requirements  to  design  for  real-time 
communications  systems  as  they  do  in  a  business  applications 
environment. 

5.2.5  Ada  Can  Be  Dsed  Throughout  the  Sysfem  Development 

liis-SisIs 

Ada  has  the  constructs  for  forming  the  base  of  a  structured 
English  for  expressing  system  requirements  and  programming 
specifications.  Therefore,  Ada  may  be  used  as  an  RSL  and  PDL 
prior  to  its  use  as  an  implementation  language.  The  use  of  5da 
throughout  the  system  development  life  cycle  reduces  the 
conversion  efforts  normally  required  tc  map  requirements  into 
design  and  design  into  code. 

5.2.6  Ada  is  flost  Compatible  with  the  Object-Oriented 
D^sjgn  Methodology 

Ada  will  support  virtually  any  methodology.  However,  it  appears 
that  Ada  is  more  compatible  with  the  object-oriented  design 
methodology  than  other  methodologies  such  as  Structured  Design, 
Jackson,  and  Harniec-Orr. 
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5.2.7  Backgrounds  of  Personnel  Developing. Ada  Systems 
j.s  Important 

Of  course,  it  is  always  important  to  match  people  with 
appropriate  backgrounds  to  development  projects.  The  best 
programmer  is  not  always  the  best  requirements  analyst  or 
designer.  Therefore,  the  personnel  assigned  to  the  requirements 
and  desiqn  phases  need  not  be  expert  Ada  programmers.  However, 
the  requirements  analysts  and  designers  need  to  have  some 
knowledge  of  Ada. 

The  requirements  analysts  should  be  familiar  with  the  basic  Ada 
constructs  if  Ada  is  used  as  an  BSL  during  the  requirements 
phase.  Designers  should  know  enough  about  Ada  to  use  it  as  a 
PDL.  Additionally,  designers  should  have  a  good  understanding  of 
Ada  program  structure  (i.e.,  subprograms  and  packages)  and 
tasking. 

5.2.8  Need  for  More  Custoiaer-Qriented  Requirements 

fixations 

ARM  is  heavily  oriented  toward  Structured  Analysis.  The  Ada 
language  is  also  key  to  ABM  since  it  is  used  to  express  the 
system  requirements.  Therefore,  the  Ada  Requirements  Document  is 
largely  DFDs  and  Ada  Requirements  Specifications.  This  format  is 
great  for  the  requirements  analysts  and  designers.  However,  from 
a  customer's  point  of  view  the  Ada  Requirements  Document  is  not  a 
good,  clear  expression  of  the  system.  The  Structured  Analysis 
and  Ada  expressions  of  the  system  need  to  be  augmented  with  more 
customer-oriented  system  requirements. 

5.2.9  Value_gf  rGi;apbic._  Illustrations 

DFDs  and  structure  charts  are  good  tools  that  facilitate 
developing  an  understanding  of  the  problem  and  solution  during 
the  requirements  and  design  phases  respectively.  However,  the 
use  of  such  tools  puts  Ada  in  a  more  supportive  role  than 
originally  anticipated.  The  graphic  illustrations  seem  to  be 
easier  to  understand  initially  than  a  pure  Ada  expression  of  the 
problem  and  solution. 

5.2.10  Strugture  Charts  are  net  Designed,  ^o , Support  Recursion 

Structure  charts  have  been  used  prolificly  during  the  design  of 
systems  to  be  implemented  in  CCBC1  or  FCHTHAN.  Since  neither  of 
these  languages  is  recursive,  there  is  no  need  fer  representing 
recursion  on  the  structure  chart.  The  lack  of  a  structure  chart 
recursion  mechanism  may  be  a  problem  when  trying  to  model  an  Ada 
solution  that  is  recursive. 

5.2.11  SBEM-type  Concurrency  Charts_are  not  Apprgpriate_f or 
Representing  the,  (joncqrrencv  of  tfae  Message  Switch  .System 

The  design  team  was  unable  tc  use  the  SHEM-type  concurrency 
charts  to  represent  the  concurrency  of  the  message  switch  system. 
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One  of  oar  consultants  tried  extensively  to  draw  a  concurrency 
chart  for  the  message  switch  system  but  was  unsuccessful.  A 
second  consultant  indicated  that  it  was  impossible  to  illustrate 
the  concurrency  of  the  message  switch  using  SRSM-type  concurrency 
charts. 

5.2. 12  Automated  Design  Aids  Could  Improve  the  Svsten 
Development  Process 

Automated  design  aids  could  be  used  to  improve  project 
management,  increase  productivity,  and  improve  the  accuracy  of 
requirements  and  design  specifications.  Specifically,  automated 
design  aids  could  be  used  to  do  the  following: 

-  Draw  DFDs 

-  Develop  traceability  matrices 

-  Structure  requirements  and  design  specifications  for 

clarity 

-  Develop  a  data  dictionary 

-  Verify  requirements  and  design  specifications. 

5.2.13  Difficulties  Associated  with  Late  , Hardware/Software 
Partitioning  jHSP) 

HSP  is  the  last  step  of  architectural  design  (after  completion  of 
a  functional  design) .  However,  experience  with  the  redesign  of 
the  message  switch  system  indicates  there  are  difficulties 
associated  with  HSP  this  late  in  the  design  process.  For 
example,  in  a  distributed  processing  environment,  the  selection 
of  separate  processors  that  use  separate  memories  could 
significantly  impact  the  functional  design.  Alsc,  the  run-time 
system  is  directly  impacted  by  the  hardware  selection (s) . 
Therefore,  late  HSP  could  result  in  inadequate  lead  time  for 
selecting  and  implementing  the  run-time  system. 

5 . 3  RECOMMENDATIONS  FOR  IMPROVING  AIM 

5.3.1  Narrative  Descriptions  of  Metjor  System.  Functions 

Add  narrative  descriptions  of  the  major  system  functions  to  the 
Ada  Requirements  Document.  This  would  be  done  after  completion 
of  the  AO  DFD. 

5.3.2  Project  Management  Considerations 

-Add  the  following  project  management  considerations: 

1.  Reviews  with  customer  at  periodic  intervals  during  the 
requirements  phase  (needed  to  ensure  accuracy  of 
requirements)  . 
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2.  Beviews  with  customer  and  management  at  periodic 
intervals  during  reguirements,  design,  and 
implementation  phases  (needed  to  ensure  that  project  is 
being  managed  properly,  within  budget,  cn  schedule, 
etc) . 

3.  Constraints  relating  tc  personnel,  time,  money,  etc. 
(needed  in  a  real-world  environment). 

4.  Implementation  considerations: 

a.  Development  of  new  procedures  and  a  user  guide 

b.  Development  of  an  operations  guide  (run  book) 

c.  Development  of  a  test  plan 

d.  Development  of  an  implementation  plan  including  a 
conversion  plan. 

5.3.3  Concurrency 

These  concurrency  modifications  are  recommended  for  AIH: 

1.  Address  concurrency  in  the  non-functional  reguirements 
part  of  ARH  instead  of  having  a  separate  part  for 
concurrency. 

2.  Eliminate  the  creation  of  concurrency  charts  during  the 
requirements  phase. 

3.  Ose  petri  nets  or  some  other  tool  for  illustrating 
concurrency  during  design  instead  of  the  SBEH-type 
concurrency  charts. 


5.3.4  Documentation  of  System  Interfaces 

Replace  the  N2  Chart  with  a  simple  module  interconnectivity  chart 
that  illustrates  all  the  interfaces  for  each  Ada  design  unit 
(i.e.,  subprogram,  package  service  (entry  point),  or  task). 


Example: 


Ada  Design  On it 

_ Inpu ts_ _ 

-Outputs. 

SOBPGB- 

PA 

” PABH2~ 

PKG1.SEBV1 

PARH3 

PABH4 

• 

PABH5 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

5.3.5  Added  Emphasis  on  Oblect-gpiented  Design 

Hake  object-oriented  design  and  information  hiding  the  main 
criteria  for  decomposing  the  system  into  modul  instead  of  the 
Structured  Design  methodclogy.  However,  continue  to  use 
Structured  Design  criteria  (i.e.,  coupling,  cohesion,  and  design 
heuristics)  to  evaluate  the  design  produced  via  an  object- 
oriented  design  methodology. 
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5.3.6  lr2£££i£i£3£i2.Q£zi£=SS3J2i£S5Sfii£-XiaSSabUi&2 


Add  the  dewelopaent  of  an  A-Specifications-to~Beguireaents 
traceability  aatrix  to  ABN. 

5.3.7  gar  dwass^Sfif  £  ware_£a£  ti  ti  csing_jioaif  isaiisjjs 

Hardware/sof tware  partitioning  needs  to  begin  earlier  in  the 
design  process,  especially  during  the  developaent  of  distributed 
processing  systeas.  Selection  of  hardware  concoaitantly  with 
functional  design  will  aitigate  the  iapact  of  hardware  selection 
on  the  functional  design. 


5.4  BBCOHHENDATIOHS  FOR  FORIHgB  RESEARCH 

5.4.1  2-fiSSSli£S-5f £§ 

Ida  was  used  as  an  RSL  to  describe  the  processing  requireoents 
within  each  priaitive  function  (block)  of  the  OFDs  developed 
during  the  reguireaents  phase.  However,  Ada  could  be  used  to 
describe  entire  CFDs,  including  all  the  interactions  between  the 
various  functions.  Concurrency  between  the  functions  of  a  DFE 
could  be  shown  via  Ada's  tasking  construct.  The  Ada 
representation  of  a  0F0  could  also  be  used  to  sake  corrections 
and  autoaatically  recreate  the  EFE  to  reflect  the  correction. 

5.4.2 

AID  places  graphic  illustrations  (structure  charts  and  M*  charts) 
before  the  Ada  representation  of  the  systea  during  the  design 
process.  This  could  be  reversed  such  that  Ada  specifications  are 
used  to  define  each  aajor  procedure  or  function  including  its 
naae,  data  structures  on  which  it  operates,  interfaces,  calls  to 
other  functions,  and  a  general  narrative  description.  The  Ada 
specifications  could  be  used  tc  generate  a  graphic  illustration 
of  the  systea  such  as  a  structure  chart. 

5.4.3 

Bith  the  advent  of  Ada  as  the  official  language  cf  the  DoD,  it 
would  seea  logical  to  change  the  project  life  cycle  to  nake  it 
aore  coapatible  with  Ada.  AIH  is  designed  to  be  conpatible  with 
Ada;  it  aakes  use  of  packaging  and  tasking,  and  uses  Ada  as  an 
HSL  and  a  PDL.  Bith  soae  aodif ications  to  add  aore  customer 
orientation  within  ABH  and  several  project  aanageaent 
considerations,  AIH  could  be  the  basis  for  developing  a  new 
ailitary  project  life  cycle. 

5.4.4  £23Sli3-2X_i!Siaa_lda_Ill£2U3k2»£_ill§_§X3£8S_ 
B8I2l2£lfiJli_liXS_£lSiS 

The  use  of  the  iapleaentation  language  to  express  systea 
requireaents  and  design  is  a  departure  froa  the  traditional 
concept  that  requireaents  and  design  aethodologies  should  be 
independent  of  the  iapleaentation  language.  Froa  this  project, 
it  seeas  that  the  use  of  Ada  during  requireaents  and  design  is 
justified.  However,  further  research  is  needed  in  this  area. 
Specifically,  Ada's  .use  as  an  BSL  to  define  the  aessage  switch 
requireaents  could  be  studied  to  deteraine  the  savings  and 
benefits  that  resulted.  It  would  also  be  interesting  to  study 
the  reasons  for  and  results  of  the  decision  to  use  the  Ada  BSL 
froa  requireaents  as  the  Ada  EEL  during  design  on  this  project. 
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5.4.5  i£ieaiaii5n_2l_fisajiis§5iEl §-§sS_fii§ias_astli2dsl2aigs 
f2I-iJl§.£e2§l2B2SDi_2f_l§alr2iae_f2§teas 

The  flow  from  requirements  to  design  required  a  "shifting  of 
gears"  or  change  in  mind  set  during  the  redesign  of  the  message 
switch  system.  The  requirements  analysts  thought  of  the  system 
as  a  single-thread  process  during  requirements  and  developed  a 
model  (DFD)  that  processed  one  entire  message  through  the  system. 
During  design,  the  requirements  analysts  of  the  requirements 
phase  became  the  designers,  and  they  shifted  gears  almost 
immediately.  They  began  to  think  more  about  the  performance 
constraints  that  were  identified  during  the  requirements  phase. 
They  began  designing  a  system  structure  that  processed  only 
segments  of  messages  at  a  time  instead  of  an  entire  message 
(because  of  performance  constraints).  In  short,  a  certain  kind 
of  thinking  or  thought  process  was  reserved  until  design.  The 
thought  process  that  was  reserved  was  incompatible  with  the 
thought  process  that  permeated  the  requirements  phase. 

Therefore,  the  EFEs  and  data  dictionary  developed  during  the 
requirements  phase  were  not  compatible  with  the  structure  chart 
and  data  structures  developed  during  design. 

It  seems  that  further  research  to  determine  how  the  problem  and 
solution  (for  a  real-tine  system)  could  be  integrated  more 
smoothly  is  appropriate.  Some  say  that  a  smooth  transition  from 
requirements  to  design  can  be  expected  in  the  business  world  but 
not  in  a  real-time  environment.  Still  it  seems  that  a  smooth 
transition  from  requirements  tc  design  is  a  worthy  goal 
regardless  of  the  type  of  system  being  developed. 

5.5  CONCLUSION 

The  application  of  AIN  during  the  redesign  of  the  message  switch 
was  successful.  However,  it  is  obvious  from  the  above  that  many 
lessons  were  learned.  Hopefully,  the  lessons  learned  and  the 
recommendations  for  improvement  and  further  research  will 
contribute  to  development  of  a  final  Ada-based  methodology. 
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